From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5EBED389942E; Tue, 22 Mar 2022 14:12:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5EBED389942E From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI Date: Tue, 22 Mar 2022 14:12:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 9.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: jason at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2022 14:12:24 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96645 Jason Merrill changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gn= u.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 par= sed > > the DMI. Given that, we have three options: > >=20 > > 1) Conservatively say no. > > 2) Optimistically guess yes. > > 3) Non-SFINAE error. > > > > ("We" in this sentence is the C++ standard.) >=20 > 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 ( whi= ch > in this example should succeed), and report failure otherwise. >=20 > ? If we can define such a best-effort attempt, it could be a candidate for standardization. > > PR81359 changed our behavior from 3 to 1. >=20 > 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 argumen= t 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 unpars= ed 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 goin= g to backport it.=