On Thu, Sep 13, 2018 at 12:42 PM, Ville Voutilainen <ville.voutilai...@gmail.com> wrote: > On 13 September 2018 at 19:36, Jason Merrill <ja...@redhat.com> wrote: >> On Thu, Sep 13, 2018 at 9:41 AM, Ville Voutilainen >> <ville.voutilai...@gmail.com> wrote: >>> On 13 September 2018 at 13:41, Ville Voutilainen >>> <ville.voutilai...@gmail.com> wrote: >>>>> How does this work when: >>>>> unsigned has_complex_copy_ctor : 1; >>>> It doesn't. I need more bits. Luckily, we have some available. >>> >>> Here. I suppose this could theoretically be done in some later stage >>> of class completion, >>> but that would presumably be an additional member function loop that >>> looks at the constructors, >>> weeds out copy constructors, and calculates the triviality bit (and it >>> should probably then also >>> look at fields and bases, again). So while I continue to have a minor >>> distaste for this whole approach, >>> and how it wastes two perfectly good bits for a dark corner case, I >>> think I can learn to live with it. >> >> Really, the problem is that trivial_fn_p shouldn't use >> type_has_trivial_fn, and also that the function named >> "type_has_trivial_fn" actually returns "type has no non-trivial fn". >> These flags are relics of C++98 semantics. Your test should also >> check that !__is_trivially_constructible(M,M&) and >> !__is_trivially_constructible(M2,M2&). > > Yeah, this patch doesn't handle those trivialities correctly, that > needs further work. > >> I suppose that given the limited number of possibly trivial >> signatures, we can still use flag bits on the class, as your patch is >> heading toward: one bit for each of the possibly trivial signatures, >> and TYPE_HAS_COMPLEX_COPY_CTOR; then TYPE_HAS_COPY_CTOR is the union >> of these. And similarly for the other possibly trivial functions. > > Okay. Do you think we should have an sfk_kind for non-canonical > copy/move operations? That would presumably make it a tad more > straightforward to go from > fndecl to whatever class bits, instead of what's currently there, where we > say "yeah I had a fndecl, > now I turned it into an sfk_kind that says it's a copy constructor, but guess > which one when you're > deeming its triviality". ;)
I suppose it would be possible to have a more detailed sfk_kind for distinguishing between different signatures, but I'm inclined instead to stop using sfk_kind in trivial_fn_p. Even if having an enumeration is convenient for dispatch (or bitmapping), it doesn't need to be the same enum. Jason
