[cxx-abi-dev] manglings for exception specifications in function types

[John McCall]

> On Nov 15, 2016, at 11:01 AM, Jason Merrill <jason at redhat.com> wrote:
> 
> On Tue, Nov 15, 2016 at 1:38 PM, Richard Smith <richardsmith at google.com> wrote:
>> On 7 November 2016 at 11:33, John McCall <rjmccall at apple.com> wrote:
>>>> On Nov 4, 2016, at 6:32 AM, Jason Merrill <jason at redhat.com> wrote:
>>>> On Thu, Nov 3, 2016 at 8:41 PM, Richard Smith <richardsmith at google.com>
>>>> wrote:
>>>>> On 3 November 2016 at 14:35, Jason Merrill <jason at redhat.com> wrote:
>>>>>> On Wed, Oct 12, 2016 at 4:51 PM, John McCall <rjmccall at apple.com>
>>>>>> wrote:
>>>>>>> On Oct 12, 2016, at 11:58 AM, Richard Smith <richardsmith at google.com>
>>>>>>> wrote:
>>>>>>>> We'll also need a new flag on type_info objects to model this. In
>>>>>>>> line
>>>>>>>> with
>>>>>>>> the transaction_safe changes that Jason proposed, I suggest adding a
>>>>>>>> __noexcept_mask = 0x40 to __pbase_type_info, and representing a
>>>>>>>> pointer
>>>>>>>> to
>>>>>>>> noexcept function as a pointer with __noexcept_mask bit set to the
>>>>>>>> corresponding *non-noexcept* function pointer type.
>>>>>>> 
>>>>>>> I strongly disagree; we should take this opportunity to revisit that
>>>>>>> decision.  The floodgates are open, and this set of function type
>>>>>>> attributes
>>>>>>> is clearly going to grow over time.  (It's actually transaction_safe
>>>>>>> that
>>>>>>> really drives this point home; noexcept is at least a longstanding
>>>>>>> part
>>>>>>> of
>>>>>>> the core language in various forms.)  We also have a lot of
>>>>>>> vendor-specific
>>>>>>> function type attributes that are part of the type but just aren't
>>>>>>> standardized and can't be represented in type_info.  I don't think it
>>>>>>> makes
>>>>>>> sense to indefinitely keep hacking these things into the pointer type
>>>>>>> flags;
>>>>>>> we should just bite the bullet and create a new function_type_info
>>>>>>> subclass.
>>>>>> 
>>>>>> But the various vendor-specific attributes don't create a different
>>>>>> type, so they shouldn't be represented in RTTI; this definitely seems
>>>>>> true of noreturn.
>>>>> 
>>>>> Whether this appears in the type_info would presumably depend on
>>>>> whether the
>>>>> implementation considers noreturn to be part of the type. Clang and GCC
>>>>> make
>>>>> somewhat different decisions here.
>>>> 
>>>> OK, but I still don't see the benefit of this change.  Since function
>>>> types can only appear in RTTI under a pointer (to member),
>>> 
>>> Well, this isn't true, for one.  Exceptions have to have object type, but
>>> typeid
>>> can be used with an arbitrary type.  But with that said...
>>> 
>>>> what is the benefit of adding a new RTTI class to store some of the
>>>> qualifiers,
>>>> wasting space and creating an ABI transition headache?
>>> 
>>> ...I am coming around to this point of view.  The existing RTTI
>>> representations are
>>> already extremely lossy and cannot usefully support a runtime reflection
>>> system, so
>>> there's no point designing with that in mind.  Our only requirements are
>>> to (1) distinguish
>>> different types and (2) support the subtyping conversions on (member)
>>> pointers
>>> mandated by the exceptions rules.  (1) is covered by way of the mangled
>>> type name,
>>> which can "represent" arbitrary type structure.  (2) is covered by your
>>> proposal to include
>>> attributes as a bitfield at the (member) pointer level.  The only
>>> considerations, then, are
>>> what attributes should be represented there and whether we're in danger of
>>> running out
>>> of space in the pointer bitfield; and I think the answers are: only the
>>> attributes
>>> meaningful for subtyping (so not, say, calling conventions), and no, we
>>> have plenty
>>> of bits remaining before we need to reserve one for extended qualifiers.
>>> 
>>> So a function pointer type like
>>>  __attribute__((fastcall)) void (*)() noexcept
>>> would be represented as a pointer_type_info with just the noexcept
>>> qualifier and
>>> with a pointee that's a function_type_info whose mangled name includes the
>>> CC attribute.
>> 
>> If we want to change our minds here, we should do it sooner rather than
>> later. Clang and libc++abi already have an implementation of the previous
>> proposal (although the Clang side is off by default due to the ABI issue).
> 
> It looks like there's consensus around your original proposal.

Agreed.

John.