public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Patrick Palka <ppalka@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-5683] c++: ICE on unviable/ambiguous constrained dtors [PR96745] Date: Fri, 3 Feb 2023 14:15:46 +0000 (GMT) [thread overview] Message-ID: <20230203141546.CEC6B3858408@sourceware.org> (raw) https://gcc.gnu.org/g:ed2b519e02eac99fadfa51adc7b11f8854c24575 commit r13-5683-ged2b519e02eac99fadfa51adc7b11f8854c24575 Author: Patrick Palka <ppalka@redhat.com> Date: Fri Feb 3 09:15:29 2023 -0500 c++: ICE on unviable/ambiguous constrained dtors [PR96745] Here we're crashing from check_bases_and_members due to CLASSTYPE_DESTRUCTOR being an OVERLOAD which, due to the pruning performed by add_method, should only happen if there is no viable destructor or the destructor is ambiguous because of unsatisfied or ambiguous constraints. This patch fixes this by making check_bases_and_members naturally handle CLASSTYPE_DESTRUCTOR being an OVERLOAD. It's then convenient to prune the OVERLOAD after effectively diagnosing the overload resolution failure in check_methods. PR c++/96745 gcc/cp/ChangeLog: * class.cc (check_methods): Diagnose an unviable OVERLOAD set for CLASSTYPE_DESTRUCTOR differently from an ambiguous one. Then prune the OVERLOAD to a single function. (check_bases_and_members): Handle CLASSTYPE_DESTRUCTOR being an OVERLOAD when calling deduce_noexcept_on_destructor. Document why it has to be called before check_methods. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-dtor1.C: New test. Diff: --- gcc/cp/class.cc | 22 +++++++++++++++++++--- gcc/testsuite/g++.dg/cpp2a/concepts-dtor1.C | 18 ++++++++++++++++++ 2 files changed, 37 insertions(+), 3 deletions(-) diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc index 40e6b7365a8..27a79829737 100644 --- a/gcc/cp/class.cc +++ b/gcc/cp/class.cc @@ -4808,9 +4808,23 @@ check_methods (tree t) in that class with an empty argument list to select the destructor for the class, also known as the selected destructor. The program is ill-formed if overload resolution fails. */ + int viable = 0; + for (tree fn : ovl_range (dtor)) + if (constraints_satisfied_p (fn)) + ++viable; + gcc_checking_assert (viable != 1); + auto_diagnostic_group d; - error_at (location_of (t), "destructor for %qT is ambiguous", t); + if (viable == 0) + error_at (location_of (t), "no viable destructor for %qT", t); + else + error_at (location_of (t), "destructor for %qT is ambiguous", t); print_candidates (dtor); + + /* Arbitrarily prune the overload set to a single function for + sake of error recovery. */ + tree *slot = find_member_slot (t, dtor_identifier); + *slot = get_first_fn (dtor); } else if (user_provided_p (dtor)) TYPE_HAS_NONTRIVIAL_DESTRUCTOR (t) = true; @@ -6048,10 +6062,12 @@ check_bases_and_members (tree t) check_bases (t, &cant_have_const_ctor, &no_const_asn_ref); /* Deduce noexcept on destructor. This needs to happen after we've set - triviality flags appropriately for our bases. */ + triviality flags appropriately for our bases, and before checking + overriden virtual functions via check_methods. */ if (cxx_dialect >= cxx11) if (tree dtor = CLASSTYPE_DESTRUCTOR (t)) - deduce_noexcept_on_destructor (dtor); + for (tree fn : ovl_range (dtor)) + deduce_noexcept_on_destructor (fn); /* Check all the method declarations. */ check_methods (t); diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-dtor1.C b/gcc/testsuite/g++.dg/cpp2a/concepts-dtor1.C new file mode 100644 index 00000000000..b1f3b4e579f --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-dtor1.C @@ -0,0 +1,18 @@ +// PR c++/96745 +// { dg-do compile { target c++20 } } + +template<class T> +struct A { // { dg-error "destructor for 'A<int>' is ambiguous" } + ~A() requires true; + ~A() requires (!!true); +}; + +A<int> a; + +template<class T> +struct B { // { dg-error "no viable destructor for 'B<int>'" } + ~B() requires false; + ~B() requires (!!false); +}; + +B<int> b;
reply other threads:[~2023-02-03 14:15 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20230203141546.CEC6B3858408@sourceware.org \ --to=ppalka@gcc.gnu.org \ --cc=gcc-cvs@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).