> On Nov 15, 2016, at 11:01 AM, Jason Merrill <[email protected]> wrote: > > On Tue, Nov 15, 2016 at 1:38 PM, Richard Smith <[email protected]> > wrote: >> On 7 November 2016 at 11:33, John McCall <[email protected]> wrote: >>>> 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. >> >> 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.
Agreed. John. _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
