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).
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
