[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Jonathan Wakely changed: What|Removed |Added CC||leanid.chaika at gmail dot com --- Comment #27 from Jonathan Wakely --- *** Bug 88165 has been marked as a duplicate of this bug. ***
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #26 from Jason Merrill --- Created attachment 52734 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52734=edit patch for tentative early DMI parsing This patch series (for GCC 13) adds a mode that tries to parse nested class DMI at the end of the nested class rather than at the end of all enclosing classes. If that fails, we try again at the later point. The first patch in the series extends our existing name-clash checking to cover nested classes as well, to catch the case where this can change name lookup results.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Jason Merrill changed: What|Removed |Added Target Milestone|12.0|13.0 Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #25 from Jason Merrill --- Reopening.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #24 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:86d8e0c0652ef5236a460b75c25e4f7093cc0651 commit r12-7960-g86d8e0c0652ef5236a460b75c25e4f7093cc0651 Author: Jason Merrill Date: Fri Apr 1 09:01:30 2022 -0400 Revert "c++: delayed parse DMI [PR96645]" The breakage from r12-7804 (in WebKit, particularly) is more of a can of worms than I think we can address in GCC 12, so let's return to the GCC 11 status quo for now and try again in stage 1. I think the change was correct for the current standard, but the standard needs a fix in this area; this is CWG issue 2335. PR c++/96645 This reverts commits r12-7804 and r12-7929.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #23 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0ce8154f1c72e6d701bff969a007938e2f986369 commit r12-7929-g0ce8154f1c72e6d701bff969a007938e2f986369 Author: Jason Merrill Date: Wed Mar 30 13:57:22 2022 -0400 c++: parse trivial DMI immediately [PR96645] The recent change to reject __is_constructible for nested classes with DMI is, unsurprisingly, breaking some code. Let's allow simple cases by immediately parsing DMI that do no name lookup; then being in complete class scope makes no difference. PR c++/96645 gcc/cp/ChangeLog: * parser.cc (cp_parser_early_parsing_nsdmi): New. (cp_parser_member_declaration): Call it. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi10.C: Now OK. * g++.dg/ext/is_constructible3.C: Likewise. * g++.dg/ext/is_constructible7.C: Likewise.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|9.5 |12.0 --- Comment #22 from Jason Merrill --- Fixed for 12, not backporting.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #21 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:346ab5a54a831ad9c78afcbd8dfe98e0e07e3070 commit r12-7804-g346ab5a54a831ad9c78afcbd8dfe98e0e07e3070 Author: Jason Merrill Date: Tue Mar 22 01:10:44 2022 -0400 c++: delayed parse DMI [PR96645] With the changes for PR81359 and PR88368 to make get_nsdmi errors be treated as substitution failure, we have the problem that if we check std::is_default_constructible for a complete class that still has unparsed default member initializers, we get an answer (false) that will be wrong once the DMIs have been parsed. The traits avoid this problem for regular incomplete classes by giving an error if the operand is incomplete; we should do the same if get_nsdmi is going to fail due to unparsed DMI. PR c++/96645 gcc/cp/ChangeLog: * cp-tree.h (type_has_default_ctor_to_be_synthesized): Declare. * class.cc (type_has_default_ctor_to_be_synthesized): New. (type_has_non_user_provided_default_constructor_1): Support it. (type_has_non_user_provided_default_constructor): Now a wrapper. * method.cc (complain_about_unparsed_dmi): New. (constructible_expr): Call it. gcc/testsuite/ChangeLog: * g++.dg/ext/is_constructible3.C: Expect error. * g++.dg/ext/is_constructible7.C: New test.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #20 from Jason Merrill --- Created attachment 52672 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52672=edit patch to make it an error for __is_constructible Thus.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #19 from Jonathan Wakely --- (In reply to Patrick Palka from comment #17) > Sounds related to PR92067, which requests that > __is_constructible(Incomplete) be a hard error. That request is far too simplistic and needs to be considered carefully. Consider the example in PR 104242, where overload resolution for the constructor has to consider the is_constructible constraints on std::any's constructor while the type is incomplete.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #18 from Eyal Rozenberg --- (In reply to Jason Merrill from comment #14) > > Alternatively, when not following the standard strictly, why should it not > > be option (4.): Ignore the official restriction on determining (nothrow) > > constructibility, make a best-effort attempt to determine it anyway ( which > > in this example should succeed), and report failure otherwise. > > > > ? > > If we can define such a best-effort attempt, it could be a candidate for > standardization. Try to resolve is_nothrow_constructible as long as this resolution does not involve DataWithMember or any of its constituents (e.g. as though we had seen the initializer expression before the definition of DataWithVariant even began). If that succeeds - we're good; if it fails - that's an error all on its own and we (sort of) don't care about the DataWithVariant error; and if it trips the wire and tries to refer to DataWithMember or a constituent thereof - give up on the parse attempt. Now, this is not _best_ effort, it's actually _minimal_ effort, since we're not willing to even accept use of A and its constituents, but it's still something. Not a candidate for standardization though.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92067 --- Comment #17 from Patrick Palka --- (In reply to Jason Merrill from comment #16) > A more targeted possiblity would be for __is_constructible to error if the > class has unparsed DMI. Sounds related to PR92067, which requests that __is_constructible(Incomplete) be a hard error.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #16 from Jason Merrill --- A more targeted possiblity would be for __is_constructible to error if the class has unparsed DMI.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #15 from Jason Merrill --- Created attachment 52663 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52663=edit patch to make dependency on unparsed DMI a hard error This doesn't seem to break anything in the library, only the two front-end tests that were specifically for the SFINAE behavior.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Summary|[9/10/11/12 Regression] |[9/10/11/12 Regression]
|std::variant default|[CWG2335] std::variant
|constructor |default constructor and
||unparsed DMI
--- Comment #14 from Jason Merrill ---
(In reply to Eyal Rozenberg from comment #12)
> (In reply to Jason Merrill from comment #8)
> > We cannot correctly resolve is_nothrow_constructible until we've parsed
> > the DMI. Given that, we have three options:
> >
> > 1) Conservatively say no.
> > 2) Optimistically guess yes.
> > 3) Non-SFINAE error.
> >
> > ("We" in this sentence is the C++ standard.)
>
> But in this page, "we" is the compiler. IIUC, the standard does not allow
> for determing is_nothrow_constructible. Am I correct? If that really is
> the case, shouldn't the compiler emit an error saying that?
Indeed, that's the question.
> Alternatively, when not following the standard strictly, why should it not
> be option (4.): Ignore the official restriction on determining (nothrow)
> constructibility, make a best-effort attempt to determine it anyway ( which
> in this example should succeed), and report failure otherwise.
>
> ?
If we can define such a best-effort attempt, it could be a candidate for
standardization.
> > PR81359 changed our behavior from 3 to 1.
>
> I searched that bug page for the rationale, and couldn't quite get it.
The patch made the error about depending on an unparsed initializer subject to
SFINAE, so that the implicit default ctor just isn't a viable candidate in this
context. So for the testcase in comment #1, A is not default-constructible
until we reach the end of DataWithStruct.
The problem comes when we cache this answer in the is_default_constructible
class; now the rest of the compilation thinks A isn't default-constructible
because we happened to check it within DataWithStruct.
This seems analogous to type completeness; if A were forward-declared, and the
definition moved after the is_default_constructible test, we'd have the same
situation. But that the standard library traits require that their argument be
complete, which avoids the caching problem at the top level, though we might
still end up caching based on the completeness of some intermediary.
The traits completeness requirement seems to suggest that making the unparsed
initializer a hard error again is the right way to go. But I'm uneasy about
making this change at this point in GCC 12 stage 4; I'm definitely not going to
backport it.
