Re: [PATCH] c++, v4: implement C++29 P2287R6 - Designated-initializers for Base Classes [PR125989]

[email protected] Wed, 5 Aug 2026 13:57:47 +0200
Newsgroups gmane.comp.gcc.patches
Message-ID <[email protected]>
Am 2026-08-05 um 13:11 schrieb Jakub Jelinek:
> On Tue, Aug 04, 2026 at 09:46:21PM -0400, Jason Merrill wrote:
>> Nice.
>>
>> But it seems to me that once we cache the lookups this way, we don't need to
>> determine the set of designators that belong to the current base; we should
>> be able to look them all up and let the normal handling work from there.
>>
>> I felt awkward about continuing to ask you for changes, so I poked at it
>> some myself.  The first patch changes reshape_init_class to avoid changing
>> d->end, and I think makes sense to combine with your patch.
> 
> Thanks.  I've looked at your first patch and it looks correct to me and indeed
> simplifies stuff.
> 
>> It would also be good to check -Wmissing-braces in at least one of the new
>> testcases.
> 
> I've added -Wmissing-braces coverage into desig14.C now, see incremental
> diff here and attached full patch (my last patch + your simplify patch
> + this incremental).
> So far tested with
> GXX_TESTSUITE_STDS=98,11,14,17,20,23,26,29 make check-g++ RUNTESTFLAGS="dg.exp='desig* feat-cxx29.C pr43765.C embed-14.C'"
> together, ok for trunk if it passes full bootstrap/regtest?
> 
>> The second patch changes _class to go through reshape_init_r for this case
>> instead of directly recursing into reshape_init_class, which avoids the
>> duplication of -Wmissing-braces handling.  This required more adjustment of
>> reshape_init_r than I expected, so I'm inclined to make it a followup, but I
>> think it's a useful clarification.
> 
> Not sure if I understood all the details but I haven't tried much yet.
> If it can go in separately, doesn't have to be done immediately.
Hmm, since I see -Wmissing-braces mentioned, is there a chance that this 
fixes/changes the c++20 behaviour reported in PR c++/126131?

Franz