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

[John McCall]

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

John.