[cxx-abi-dev] manglings for exception specifications in function types
Jason Merrill
jason at redhat.com
Fri Nov 4 13:32:48 UTC 2016
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), what is the
benefit of adding a new RTTI class to store some of the qualifiers,
wasting space and creating an ABI transition headache?
Jason
More information about the cxx-abi-dev
mailing list