[cxx-abi-dev] Re: Mangling of member functions in decltype expressions

[John McCall]

On Mar 1, 2010, at 10:19 AM, Jason Merrill wrote:

> On 02/26/2010 03:56 PM, Mike Herrick wrote:
>> Consider:
>> 
>>   struct A {
>>     void f(int);
>>   } a;
>>   template<class T>  auto f(T p1) ->  decltype(a.f(p1));
>>   int main() {
>>     f(0);
>>   }
>> 
>> g++ 4.4.3 mangles f as "_Z1fIiEDTcldtL_Z1aEL_ZN1A1fEiEfp_EET_" which g++ demangles as:
>> 
>> decltype ((a.(A::f(int)))(parm#1)) f<int>(int)
>> 
>> However, I can't seem to demangle this with the existing IA-64 ABI rules.  Using:
>> 
>>              ::= dt<expression>  <unqualified-name>               # expr.name
>> 
>> I'm able to match "L_Z1aE" to<expression>, but<unqualified-name>  doesn't reduce to<expr-primary>  (which is what I presume "L_ZN1A1fEiE" represents).
>> 
>> Do you consider this a g++ bug (and a qualified name should not be used), or a problem with the current IA-64 ABI specification?  What do you believe the correct mangling should be?
> 
> I don't feel strongly one way or the other, but I think the G++ output makes sense; I think there are other places we use the full mangled name for non-dependent names, and a plain identifier for dependent ones.

I think this can't just be <unqualified-name>:

struct AmbiguousBase { int foo; };
struct Edge1 : AmbiguousBase { float bar; };
struct Edge2 : AmbiguousBase { double bar; };
struct Derived : Edge1, Edge2 {};
Derived object;

So we need to represent the qualifier / base-path somehow.  The obvious choice for the dependent case is to use <unqualified-name> | <nested-name>, which is still unambiguous.  I think the ambiguous base problem strongly recommends the same solution in the non-dependent case, but I'm willing to consider using something like <expr-primary> when it's unambiguous, although that does seem like a lot of potential analysis for the mangler.

Clang is currently mangling these as <unqualified-name> | <nested-name>, but we're obviously not constrained by the existence of users yet. :)

John.