[cxx-abi-dev] Mangling ambiguity with argument packs in template argument lists

[Mike Herrick]

On Jan 20, 2011, at 7:24 PM, Doug Gregor wrote:

> On Mon, Dec 20, 2010 at 9:41 AM, Mike Herrick <mjh at edg.com> wrote:
>> We ran into a mangling ambiguity with argument packs in template argument lists (where both use the letter "I"):
>> 
>>  <template-args> ::= I <template-arg>+ E
>>  <template-arg> ::= <type>                         # type or template
>>                 ::= X <expression> E               # expression
>>                 ::= <expr-primary>                 # simple expressions
>>                 ::= I <template-arg>* E            # argument pack
>>                 ::= sp <expression>                # pack expansion (C++0x)
>> 
>> Here's an example where two different source constructs generate the same mangled name (_Z1fI1BI1AIiEEEDTcmfp_fp_ET_):
>> 
>> $ cat foo.cpp
>>  template <class T> auto f(T p1) -> decltype(p1, p1);
>>  template <class T> struct A {};
>> #if FOO
>>  template <class T> struct B {};
>>  B<A<int>> b;
>> #else
>>  template <template <class TT> class T, class ... U> struct B {};
>>  B<A,int> b;
>> #endif
>>  int main() {
>>    f(b);
>>  }
>> $ g++451 -DFOO -std=c++0x foo.cpp
>> /tmp/ccOqFYBI.o(.text+0xc): In function `main':
>> : undefined reference to `decltype ({parm#1},{parm#1}) f<B<A<int> > >(B<A<int> >)'
>> collect2: ld returned 1 exit status
>> $ g++451 -UFOO -std=c++0x foo.cpp
>> /tmp/cc448n5U.o(.text+0xc): In function `main':
>> : undefined reference to `decltype ({parm#1},{parm#1}) f<B<A<int> > >(B<A<int> >)'
>> collect2: ld returned 1 exit status
>> $
>> 
>> When the demangler gets to the "I" after "1A", it's ambiguous whether the "I" represents an argument pack or a template argument (as noted by g++ 4.5.1 issuing the same demangled name for both cases).
>> 
>> To address this, we propose changing the mangling for argument packs to use "J" rather than "I":
>> 
>>  <template-arg> ::= J <template-arg>* E              # argument pack
>> 
>> This change is not backward compatible.
>> 
>> I'm attaching a patch that includes this change with the others that I've proposed.
> 
> These changes seem perfectly reasonable to me.

Thanks, Doug.

Are there any other comments (particularly on the backward-incompatible nature of this change, say from any implementations that have already implemented it)?

Mike.