public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-96645-4-TWo6at856E@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-96645-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Jason Merrill <jason at gcc dot gnu.org> 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 <jason at gcc dot gnu.org> --- (In reply to Eyal Rozenberg from comment #12) > (In reply to Jason Merrill from comment #8) > > We cannot correctly resolve is_nothrow_constructible<A> 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<A>. 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.
next prev parent reply other threads:[~2022-03-22 14:12 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-17 7:58 [Bug libstdc++/96645] New: std::variant default constructor dev at hrookami dot icu 2020-08-17 14:21 ` [Bug c++/96645] [9/10/11 Regression] " redi at gcc dot gnu.org 2020-08-17 14:24 ` dev at hrookami dot icu 2020-08-17 14:30 ` redi at gcc dot gnu.org 2020-08-17 14:40 ` redi at gcc dot gnu.org 2020-08-18 7:49 ` dev at hrookami dot icu 2020-08-25 10:31 ` rguenth at gcc dot gnu.org 2020-10-12 12:33 ` rguenth at gcc dot gnu.org 2021-01-25 13:53 ` jakub at gcc dot gnu.org 2021-02-15 15:28 ` ppalka at gcc dot gnu.org 2021-04-02 18:20 ` jason at gcc dot gnu.org 2021-04-02 18:21 ` jason at gcc dot gnu.org 2021-04-03 11:27 ` redi at gcc dot gnu.org 2021-06-01 8:18 ` [Bug c++/96645] [9/10/11/12 " rguenth at gcc dot gnu.org 2021-09-06 19:56 ` eyalroz1 at gmx dot com 2021-11-23 17:08 ` redi at gcc dot gnu.org 2022-03-22 14:12 ` jason at gcc dot gnu.org [this message] 2022-03-22 16:15 ` [Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI jason at gcc dot gnu.org 2022-03-22 16:22 ` jason at gcc dot gnu.org 2022-03-22 17:31 ` ppalka at gcc dot gnu.org 2022-03-22 20:56 ` eyalroz1 at gmx dot com 2022-03-22 21:29 ` redi at gcc dot gnu.org 2022-03-23 13:36 ` jason at gcc dot gnu.org 2022-03-24 18:31 ` cvs-commit at gcc dot gnu.org 2022-03-26 23:22 ` jason at gcc dot gnu.org 2022-03-31 1:43 ` cvs-commit at gcc dot gnu.org 2022-04-01 14:00 ` cvs-commit at gcc dot gnu.org 2022-04-01 14:07 ` jason at gcc dot gnu.org 2022-04-01 14:14 ` jason at gcc dot gnu.org 2022-04-22 8:26 ` redi at gcc dot gnu.org 2022-05-15 6:35 ` [Bug c++/96645] [9/10/11/12/13 " pinskia at gcc dot gnu.org 2022-08-15 4:53 ` [Bug c++/96645] [10/11/12/13 " pinskia at gcc dot gnu.org 2023-04-26 6:55 ` [Bug c++/96645] [10/11/12/13/14 " rguenth at gcc dot gnu.org 2023-07-27 9:22 ` [Bug c++/96645] [11/12/13/14 " rguenth at gcc dot gnu.org 2024-05-21 9:10 ` [Bug c++/96645] [11/12/13/14/15 " jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-96645-4-TWo6at856E@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).