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

[Richard Smith]

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20161115/ab3ac588/attachment.html>