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