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'. 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
