[C++ PATCH] PR c++/87051

[Jason Merrill]

On Thu, Sep 13, 2018 at 12:42 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 13 September 2018 at 19:36, Jason Merrill <jason@redhat.com> wrote:
>> On Thu, Sep 13, 2018 at 9:41 AM, Ville Voutilainen
>> <ville.voutilainen@gmail.com> wrote:
>>> On 13 September 2018 at 13:41, Ville Voutilainen
>>> <ville.voutilainen@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