public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Marek Polacek <polacek@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: [PATCH v2] c++: wrong looser excep spec for dep noexcept [PR113158]
Date: Fri, 16 Feb 2024 16:33:43 -0500	[thread overview]
Message-ID: <Zc_Ut5vW7Hzd05Dy@redhat.com> (raw)
In-Reply-To: <6db4134a-3a48-4ed4-bbbf-914a4ea66f3d@redhat.com>

On Fri, Feb 16, 2024 at 03:58:02PM -0500, Jason Merrill wrote:
> On 2/15/24 17:17, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > By the ??? below I mean that maybe_instantiate_noexcept could return
> > a tristate, and then maybe_check_overriding_exception_spec could check
> > 
> >    if (maybe_instantiate_noexcept ().is_unknown ())
> >      return true;
> > 
> > and we don't have to add any new checks to maybe_check_o_e_spec.
> > 
> > -- >8 --
> > Here we find ourselves in maybe_check_overriding_exception_spec in
> > a template context where we can't instantiate a dependent noexcept.
> > That's OK, but we have to defer the checking otherwise we give wrong
> > errors.
> > 
> > 	PR c++/113158
> > 
> > gcc/cp/ChangeLog:
> > 
> > 	* search.cc (maybe_check_overriding_exception_spec): Defer checking
> > 	when a noexcept couldn't be instantiated.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 	* g++.dg/cpp0x/noexcept83.C: New test.
> > ---
> >   gcc/cp/search.cc                        |  7 +++++
> >   gcc/testsuite/g++.dg/cpp0x/noexcept83.C | 37 +++++++++++++++++++++++++
> >   2 files changed, 44 insertions(+)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept83.C
> > 
> > diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
> > index c948839dc53..73d254d6b84 100644
> > --- a/gcc/cp/search.cc
> > +++ b/gcc/cp/search.cc
> > @@ -1975,6 +1975,13 @@ maybe_check_overriding_exception_spec (tree overrider, tree basefn)
> >         || UNPARSED_NOEXCEPT_SPEC_P (over_throw))
> >       return true;
> > +  /* We also have to defer checking when we're in a template and couldn't
> > +     instantiate the noexcept yet.
> > +     ??? maybe_instantiate_noexcept already checked these.  Use tristate?  */
> > +  if (type_dependent_expression_p (base_throw)
> > +      || type_dependent_expression_p (over_throw))
> 
> I think we also want to avoid comparing value-dependent expressions, but
> actually checking either one seems like more work than needed here; I'd
> think we want to defer in a template if the specifiers aren't both exactly
> true or false.

Yeah, that'll work too.  So like this?

Bootstrap/regtest running; dg.exp passed.  FWIW, the new check only
triggered on the new test.

Thanks,

-- >8 --
Here we find ourselves in maybe_check_overriding_exception_spec in
a template context where we can't instantiate a dependent noexcept.
That's OK, but we have to defer the checking otherwise we give wrong
errors.

	PR c++/113158

gcc/cp/ChangeLog:

	* search.cc (maybe_check_overriding_exception_spec): Defer checking
	when a noexcept couldn't be instantiated & evaluated to false/true.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/noexcept83.C: New test.
---
 gcc/cp/search.cc                        | 11 ++++++++
 gcc/testsuite/g++.dg/cpp0x/noexcept83.C | 37 +++++++++++++++++++++++++
 2 files changed, 48 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept83.C

diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
index c948839dc53..554ba71f4a7 100644
--- a/gcc/cp/search.cc
+++ b/gcc/cp/search.cc
@@ -1975,6 +1975,17 @@ maybe_check_overriding_exception_spec (tree overrider, tree basefn)
       || UNPARSED_NOEXCEPT_SPEC_P (over_throw))
     return true;
 
+  /* We also have to defer checking when we're in a template and couldn't
+     instantiate & evaluate the noexcept to true/false.  */
+  if (processing_template_decl)
+    if ((base_throw
+	 && (base_throw != noexcept_true_spec
+	     || base_throw != noexcept_false_spec))
+	|| (over_throw
+	    && (over_throw != noexcept_true_spec
+		|| over_throw != noexcept_false_spec)))
+      return true;
+
   if (!comp_except_specs (base_throw, over_throw, ce_derived))
     {
       auto_diagnostic_group d;
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept83.C b/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
new file mode 100644
index 00000000000..47832bbb44d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
@@ -0,0 +1,37 @@
+// PR c++/113158
+// { dg-do compile { target c++11 } }
+
+template<typename T>
+struct V {
+  static constexpr bool t = false;
+};
+struct base {
+    virtual int f() = 0;
+};
+
+template<typename T>
+struct derived : base {
+    int f() noexcept(V<T>::t) override;
+};
+
+struct base2 {
+    virtual int f() noexcept = 0;
+};
+
+template<bool B>
+struct W {
+  static constexpr bool t = B;
+};
+
+template<bool B>
+struct derived2 : base2 {
+    int f() noexcept(W<B>::t) override; // { dg-error "looser exception specification" }
+};
+
+void
+g ()
+{
+  derived<int> d1;
+  derived2<false> d2; // { dg-message "required from here" }
+  derived2<true> d3;
+}

base-commit: 40b8d7b73ad2ce498758c1d9bd38ebdbc26b918b
-- 
2.43.2


  reply	other threads:[~2024-02-16 21:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 22:17 [PATCH] " Marek Polacek
2024-02-16 20:58 ` Jason Merrill
2024-02-16 21:33   ` Marek Polacek [this message]
2024-02-16 21:39     ` [PATCH v2] " Patrick Palka
2024-02-16 22:06       ` [PATCH v3] " Marek Polacek
2024-02-17 10:07         ` Jason Merrill

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=Zc_Ut5vW7Hzd05Dy@redhat.com \
    --to=polacek@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /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: link
Be 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).