[C++] Avoid some duplicate error messages

Message ID 03cd0dbc-6e5e-a643-5618-a7b94379298a@oracle.com
State New
Headers show
Series
  • [C++] Avoid some duplicate error messages
Related show

Commit Message

Paolo Carlini April 29, 2019, 6:50 p.m.
Hi,

I have a small back queue of tweaks of various kinds and sizes, this one 
seems small enough to be safe wrt last minute release branch fixes.

While working on the regression c++/88969, some duplicate errors showed 
up when we started giving appropriate diagnostics instead of ICEing, 
which could be cured by unconditionally returning error_mark_node from 
cp_build_function_call_vec when mark_used fails. In general, in the 
front-end we have a mix of unconditional and conditional to SFINAE 
context mark_used checks, I think it's often a delicate choice, the 
below change passes testing, I would give it a spin, at the beginning of 
Stage1. Tested x86_64-linux.

Thanks, Paolo.

////////////////////////
/cp
2019-04-29  Paolo Carlini  <paolo.carlini@oracle.com>

	* typeck.c (cp_build_function_call_vec): When mark_used fails
	unconditionally return error_mark_node.

/testsuite
2019-04-29  Paolo Carlini  <paolo.carlini@oracle.com>

	* g++.dg/cpp2a/multiple-deleted-destroying-delete-error-1.C: New.
	* g++.dg/cpp2a/multiple-deleted-destroying-delete-error-2.C: Likewise.

Comments

Jason Merrill May 10, 2019, 2:44 p.m. | #1
On 4/29/19 2:50 PM, Paolo Carlini wrote:
> Hi,

> 

> I have a small back queue of tweaks of various kinds and sizes, this one 

> seems small enough to be safe wrt last minute release branch fixes.

> 

> While working on the regression c++/88969, some duplicate errors showed 

> up when we started giving appropriate diagnostics instead of ICEing, 

> which could be cured by unconditionally returning error_mark_node from 

> cp_build_function_call_vec when mark_used fails. In general, in the 

> front-end we have a mix of unconditional and conditional to SFINAE 

> context mark_used checks, I think it's often a delicate choice, the 

> below change passes testing, I would give it a spin, at the beginning of 

> Stage1. Tested x86_64-linux.


OK.

Jason

Patch

Index: cp/typeck.c
===================================================================
--- cp/typeck.c	(revision 270643)
+++ cp/typeck.c	(working copy)
@@ -3837,7 +3837,7 @@  cp_build_function_call_vec (tree function, vec<tre
           return error_mark_node;
         }
 
-      if (!mark_used (function, complain) && !(complain & tf_error))
+      if (!mark_used (function, complain))
 	return error_mark_node;
       fndecl = function;
 
Index: testsuite/g++.dg/cpp2a/multiple-deleted-destroying-delete-error-1.C
===================================================================
--- testsuite/g++.dg/cpp2a/multiple-deleted-destroying-delete-error-1.C	(nonexistent)
+++ testsuite/g++.dg/cpp2a/multiple-deleted-destroying-delete-error-1.C	(working copy)
@@ -0,0 +1,12 @@ 
+// { dg-do compile { target c++2a } }
+
+#include <new>
+
+namespace delete_selection_d {
+  struct B {
+    void operator delete(void*) = delete;
+    void operator delete(B *, std::destroying_delete_t) = delete;
+  };
+  void delete_B(B *b) { delete b; }  // { dg-bogus "deleted .* deleted" }
+  // { dg-error "deleted" "" { target c++2a } .-1 }
+}
Index: testsuite/g++.dg/cpp2a/multiple-deleted-destroying-delete-error-2.C
===================================================================
--- testsuite/g++.dg/cpp2a/multiple-deleted-destroying-delete-error-2.C	(nonexistent)
+++ testsuite/g++.dg/cpp2a/multiple-deleted-destroying-delete-error-2.C	(working copy)
@@ -0,0 +1,12 @@ 
+// { dg-do compile { target c++2a } }
+
+#include <new>
+
+namespace delete_selection_r {
+  struct B {
+    void operator delete(B *, std::destroying_delete_t) = delete;
+    void operator delete(void*) = delete;
+  };
+  void delete_B(B *b) { delete b; }  // { dg-bogus "deleted .* deleted" }
+  // { dg-error "deleted" "" { target c++2a } .-1 }
+}