[cxx-abi-dev] Missing mangling of elaborated type specifiers

[John McCall]

On Mar 26, 2014, at 11:34 AM, Richard Smith <richardsmith at google.com> wrote:
> On 20 March 2014 12:04, John McCall <rjmccall at apple.com> wrote:
> On Mar 20, 2014, at 11:16 AM, Hubert Tong <hstong at ca.ibm.com> wrote:
> > John McCall <rjmccall at apple.com> wrote on 20-03-2014 01:56:10 PM:
> > > From: John McCall <rjmccall at apple.com>
> > > To: Hubert Tong/Toronto/IBM at IBMCA,
> > > Cc: cxx-abi-dev at codesourcery.com
> > > Date: 20-03-2014 01:56 PM
> > > Subject: Re: [cxx-abi-dev] Missing mangling of elaborated type specifiers
> > >
> > > On Mar 19, 2014, at 9:02 PM, Hubert Tong <hstong at ca.ibm.com> wrote:
> > > > It seems that the ABI is missing mangling for elaborated type specifiers.
> > > >
> > > > Background:
> > > > As mentioned in Core Issue 1162, elaborated-type-specifiers may be
> > > used to cause SFINAE.
> > >
> > > Good point.  I guess this should just be added to <unresolved-name>.
> > > Would you care to make a proposal?
> > >
> >
> > Sure.
> 
> Great!
> 
> I think I was wrong, by the way; you should add it to to the <class-enum-type> grammar as a decoration before we enter <name>.
> 
> I think we should leave the 'typename' case alone and change the struct/class/union/enum cases, since the latter cases are much less common. There seem to be two obvious approaches:
> 
> 1) Use a prefix indicating that there was a tag keyword, but don't say which one.
> 2) Use a prefix indicating which keyword was used
> 
> The first approach seems viable -- we can never have a mangling collision where a type is one of struct-or-class, union, or enum in one TU and a different one of those three in another TU (and the struct and class cases are functionally equivalent).

Sorry, what?  Why are any of these the same function template under the ODR?
  template <class T> auto f() -> enum T::type;
  template <class T> auto f() -> struct T::type;
  template <class T> auto f() -> typename T::type;
Template argument deduction can distinguish the first two (and drop them in favor of the third for typedef members), and the third can be introduced later or in a different translation unit.

I think we have to take the second approach.

> The second approach seems better for demanglers (and taking that argument to its logical conclusion suggests that we should mangle 'class' and 'struct' differently).
> 
> Strawman:
> 
> <class-enum-type> ::= <name>    # non-dependent type name or typename-specifier
>                   ::= TC <name> # dependent elaborated class type
>                   ::= Ts <name> # dependent elaborated struct type
>                   ::= Tu <name> # dependent elaborated union type
>                   ::= Te <name> # dependent elaborated enum type 

I don’t think distinguishing struct and class is worth it.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140326/a7371540/attachment.html>