On 5 May 2015 at 18:17, Jason Merrill <[email protected]> wrote: > On 05/05/2015 05:31 PM, John McCall wrote: > >> These qualifiers aren’t order-sensitive, so we need to specify the order; >> alphabetical order is the most obvious, which I think would make this >> mangling U11regparmLi3EU7stdcallFviiE rather than the other way around. >> > > For member pointer types, this would become part of the member type. >> That’s also where we put ref-qualifiers and CV-qualifiers, so we need to >> specify an order; I suggest putting these attributes after the CV/ref >> qualifiers. >> > > I was working from the passage in the ABI that says, "In cases where > multiple order-insensitive qualifiers are present, they should be ordered > 'K' (closest to the base type), 'V', 'r', and 'U' (farthest from the base > type), with the 'U' qualifiers in alphabetical order by the vendor name > (with alphabetically earlier names closer to the base type)." > > So I think reverse alphabetical order before the CV-qualifiers is what we > want. > > Should we mangle these as part of an entity’s type? It’s not possible to >> directly overload using the CC of a function itself, so it’s not strictly >> necessary. There’s a general issue with overloading function templates by >> the types of non-type template parameters, but I don’t think it affects us >> in this specific case because the argument itself resolves the ambiguity. >> > > Microsoft mangles functions differently based on the calling convention, > but I agree that it doesn't seem to be necessary. > > On 05/05/2015 06:40 PM, Richard Smith wrote: > >> It seems a little weird to nest a mangling within a source-name like that. >> > > Fair enough, I was experimenting with something that wouldn't require any > changes to the ABI or demanglers. > > We had some previous discussion of arguments for vendor extensions here: >> >> http://sourcerytools.com/pipermail/cxx-abi-dev/2014-January/002660.html >> > > Thanks for the reminder. > > It looks like we ended up mangling >> >> void f(bool b) __attribute__((enable_if(b, "foo"))) {} >> >> as >> >> _Z1fUa9enable_ifIXfL0p_EEb >> >> ... where Ua means roughly "vendor attribute", and is followed by >> <source-name> <template-args>. With that approach, those attributes would >> mangle as Ua7regparmIXLi3EE and Ua7stdcallIE >> > > What I see in that thread is "U", not "Ua". And indeed, that seems > unambiguous; no type can begin with 'I'.
The reason we chose Ua rather than U was that the ABI suggests that U4blah should demangle as 'blah', whereas we want something that demanglers know should become '__attribute__((blah))'. I have no particular strong feelings here. > So, changing > ::= U <source-name> <type> # vendor extended type qualifier > to > ::= U <source-name> <type> [ <template-args> ] > > Also, I think the 3 should use the expr-primary mangling, and it doesn't > seem necessary to attach the "IE" to stdcall. So, > > U7regparmILi3EE > U7stdcall > > Make sense? > > Jason > > > _______________________________________________ > cxx-abi-dev mailing list > [email protected] > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev >
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
