> On Nov 4, 2016, at 6:32 AM, Jason Merrill <[email protected]> wrote: > > On Thu, Nov 3, 2016 at 8:41 PM, Richard Smith <[email protected]> wrote: >> On 3 November 2016 at 14:35, Jason Merrill <[email protected]> wrote: >>> >>> On Wed, Oct 12, 2016 at 4:51 PM, John McCall <[email protected]> wrote: >>>> On Oct 12, 2016, at 11:58 AM, Richard Smith <[email protected]> >>>> 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. _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
