[cfe-dev] Invalid mangled names emitted for local types declared in Apple Block expressions used in non-static data member initializers

[John McCall via cfe-dev]

> On Sep 6, 2017, at 11:00 PM, Tom Honermann <Thomas.Honermann at synopsys.com> wrote:
> On 9/6/2017 7:13 PM, John McCall wrote:
>> 
>>> On Sep 6, 2017, at 5:50 PM, Richard Smith <richard at metafoo.co.uk 
>>>    The mangled name generated for the function template specialization
>>>    instantiated for the local enum type 'E' uses a
>>>    <pointer-to-member-type>
>>>    production [1] (as signified by 'M'),
>>> 
>>> 
>>> I believe you're mistaken. This is not a context in which a <type> 
>>> production can appear. That's a <data-member-prefix>:
>>> 
>>> http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.data-member-prefix 
> 
> Ah, so it is.  Thanks for the correction.
> 
>>> This behavior looks correct to me, except that I'm surprised that this 
>>> block is numbered as Ub0_ instead of Ub_. Looks like we have an 
>>> off-by-one error here, introduced in r214699 while fixing a different 
>>> off-by-one error.
>>> 
>>> John: should we restore the pre-r214699 ABI, or would you prefer that 
>>> we just accept the new mangling as our ABI now?
>> 
>> Nothing about blocks ever has identity across translation units, so 
>> there's no harm in fixing the bug and restoring the original ABI to 
>> start counting at b_.
> 
> That doesn't seem right to me.  For example, aren't static local 
> variables declared within block expressions in inline functions required 
> to match across TUs?

Ah, yes, you're right; I was thinking of the data directly associated with the block
without considering its contents.

> Granted, this is a fairly contrived example, so restoring the original 
> ABI doesn't strike me as very likely to cause problems.

Yeah, I think it's better to just fix the bug.  I'm not too worried about this level of contrivance.

John.