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

[Richard Smith]

On 26 March 2014 11:59, John McCall <rjmccall at apple.com> wrote:

> 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.
>

The first two are not the same function template. But that doesn't matter,
as far as I can see -- we don't have mangled names for function templates,
we have mangled names for function template specializations, and there
cannot exist template arguments for which substitution into the first two
function templates both succeed.

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.
>

I agree that the benefit of a demangler being able to say whether it's got
a class or struct is marginal. Maybe drop the 'TC' mangling and keep the
other three?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140326/0f23a4ff/attachment-0001.html>