> On Feb 18, 2015, at 11:46 AM, Richard Smith <[email protected]> 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? John. _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
