[cxx-abi-dev] manglings for exception specifications in function types
Richard Smith
richardsmith at google.com
Fri Nov 4 00:41:50 UTC 2016
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20161103/b33edcee/attachment.html>
More information about the cxx-abi-dev
mailing list