[cxx-abi-dev] missing mangling for <template-param> <template-args> in <unresolved-name>

[Richard Smith]

On 18 February 2015 at 13:04, John McCall <rjmccall at apple.com> wrote:

> > On Feb 18, 2015, at 11:46 AM, Richard Smith <richardsmith at google.com>
> wrote:
> > Consider these two cases:
> >
> > template<typename T> struct X { struct Y {}; };
> >
> > template<template<typename> class U> decltype(X<int>().~U<int>()) f();
> > template<template<typename> class U>
> decltype(X<int>::Y().U<int>::Y::~Y()) g();
> >
> > Neither of these function templates has a mangling. We get to
> <unresolved-name> for the destructor name, and find a template template
> parameter with template args, which we cannot mangle as an
> <unresolved-type>, and must not mangle as a <simple-id> (because the name
> of the template template parameter can change between redeclarations).
> >
> > Suggested fix: U<int> should be an <unresolved-type>. Replace
> >
> >   <unresolved-type> ::= <template-param>
> >
> > with
> >
> >   <unresolved-type> ::= <template-param> [ <template-args> ]
> >
> > ... which results, I think, in these manglings for f<X> and g<X>:
> >
> > _Z1fI1XEDTcldtcvS0_IiE_EdnT_IiEEEv
> > _Z1gI1XEDTcldtcvNS0_IiE1YE_EsrNT_IiE1YEdn1YEEv
> >
> > (Clang trunk implements this, but gets the g<X> mangling wrong for other
> reasons.)
> >
> > OK?
>
> I had to go and convince myself that an optional dangling production is
> fine here, but it does look like it can unambiguously and unheroically
> demangled.  There are several other major productions that use an optional
> dangling <template-args> like this, most notably <simple-id>; so while this
> is not my favorite way of designing a mangling, it’s widely precedented in
> the grammar with this exact production, so the rest of the grammar has been
> designed to not collide with it.  I did go ahead and verify that it’s
> unambiguous anyway.  So this looks good to me.
>
> Is ~T::T() legal with a template parameter, or does that actually look up
> “T" in the template argument?


It depends on whether the base object has a dependent type. If x's type is
not dependent, then x.T::~T() looks up the first T within the type and
names the template parameter if T is not found within the type. If x's type
is dependent, (the standard is not clear but) lookup within the class is
deemed to fail and the first T always names the template parameter. In all
cases, the second T is looked up in the same scope(s) as the first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20150218/c40191ff/attachment.html>