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

[Jason Merrill]

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.  John's
elaboration here sounds right to me.

Jason