[cxx-abi-dev] Mangling of calling convention attributes

[Jason Merrill]

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