Re: [PATCH] c++: -Wuninitialized when binding a ref to uninit DM [PR113987]

[Jason Merrill <jason@redhat.com>]

On 2/22/24 14:28, Marek Polacek wrote:
> On Thu, Feb 22, 2024 at 08:34:45AM +0000, Jason Merrill wrote:
>> On 2/20/24 19:15, Marek Polacek wrote:
>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>>>
>>> -- >8 --
>>> This PR asks that our -Wuninitialized for mem-initializers does
>>> not warn when binding a reference to an uninitialized data member.
>>> We already check !INDIRECT_TYPE_P in find_uninit_fields_r, but
>>> that won't catch binding a parameter of a reference type to an
>>> uninitialized field, as in:
>>>
>>>     struct S { S (int&); };
>>>     struct T {
>>>         T() : s(i) {}
>>>         S s;
>>>         int i;
>>>     };
>>>
>>> This patch adds a new function to handle this case.
>>
>> For type_build_ctor_call types like S, it's weird that we currently
>> find_uninit_fields before building the initialization.  What if we move the
>> check after the build_aggr_init so we have the actual initializer instead of
>> just the expression?
> 
> Thanks.  I've tried but unfortunately I'm not getting anywhere.  One
> problem is that immediately after the find_uninit_fields call we may
> change the TREE_LIST in
> 
>    if (init && TREE_CODE (init) == TREE_LIST)
>       //...
> 
> so we'd have to cope with that somehow.  Sinking find_uninit_fields
> into one of the conditions below looks like a complication.  Another
> problem is that calling find_uninit_fields on the result of
> build_aggr_init call causes a bogus warning: we create something like
> E::E (&((struct F *) this)->e, ((struct F *) this)->a)
> and then warn that the this object is uninitialized.  So I'm not sure
> if that fix would be simpler.

Fair enough, the patch is OK.

Jason