public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [C++ Patch] PR 68754 ("Explicitly defaulted constexpr assignment operator fails to compile")
@ 2017-09-29 17:04 Paolo Carlini
  2017-09-29 19:12 ` Nathan Sidwell
  0 siblings, 1 reply; 2+ messages in thread
From: Paolo Carlini @ 2017-09-29 17:04 UTC (permalink / raw)
  To: gcc-patches; +Cc: Jason Merrill, Nathan Sidwell

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

Hi,

the main issue, a C++14 rejects-valid, is already fixed in trunk, and a 
while ago I added a testcase for that. However, Andrew noticed that in 
C++11 mode we emit redundant and also a bit puzzling diagnostic (ending 
with one of those annoying "... because:" and nothing after which 
unfortunately we emit in some other cases too). Comparing to, eg, clang 
too, I think we can make progress by simply returning early after the 
first hard error. Also, as an additional tweak, we might replace the 
second error with an inform, per the usual scheme. Tested x86_64-linux.

Thanks, Paolo.

//////////////////////////


[-- Attachment #2: CL_68754_2 --]
[-- Type: text/plain, Size: 368 bytes --]

/cp
2017-09-29  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/68754
	* method.c (defaulted_late_check): Early return if the defaulted
	declaration does not match the expected signature.

/testsuite
2017-09-29  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/68754
	* g++.dg/cpp1y/constexpr-68754.C: Move...
	* g++.dg/cpp0x/constexpr-68754.C: ... here, adjust.

[-- Attachment #3: patch_68754_2 --]
[-- Type: text/plain, Size: 1722 bytes --]

Index: cp/method.c
===================================================================
--- cp/method.c	(revision 253283)
+++ cp/method.c	(working copy)
@@ -2191,9 +2191,11 @@ defaulted_late_check (tree fn)
       || !compparms (TYPE_ARG_TYPES (TREE_TYPE (fn)),
 		     TYPE_ARG_TYPES (TREE_TYPE (implicit_fn))))
     {
-      error ("defaulted declaration %q+D", fn);
-      error_at (DECL_SOURCE_LOCATION (fn),
-		"does not match expected signature %qD", implicit_fn);
+      error ("defaulted declaration %q+D does not match the "
+	     "expected signature", fn);
+      inform (DECL_SOURCE_LOCATION (fn),
+	      "expected signature: %qD", implicit_fn);
+      return;
     }
 
   if (DECL_DELETED_FN (implicit_fn))
Index: testsuite/g++.dg/cpp0x/constexpr-68754.C
===================================================================
--- testsuite/g++.dg/cpp0x/constexpr-68754.C	(revision 253283)
+++ testsuite/g++.dg/cpp0x/constexpr-68754.C	(working copy)
@@ -1,7 +1,7 @@
 // PR c++/68754
-// { dg-do compile { target c++14 } }
+// { dg-do compile { target c++11 } }
 
 struct base { };
 struct derived : base {
-  constexpr derived& operator=(derived const&) = default;
+  constexpr derived& operator=(derived const&) = default; // { dg-error "defaulted declaration" "" { target { ! c++14 } } }
 };
Index: testsuite/g++.dg/cpp1y/constexpr-68754.C
===================================================================
--- testsuite/g++.dg/cpp1y/constexpr-68754.C	(revision 253283)
+++ testsuite/g++.dg/cpp1y/constexpr-68754.C	(working copy)
@@ -1,7 +0,0 @@
-// PR c++/68754
-// { dg-do compile { target c++14 } }
-
-struct base { };
-struct derived : base {
-  constexpr derived& operator=(derived const&) = default;
-};

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [C++ Patch] PR 68754 ("Explicitly defaulted constexpr assignment operator fails to compile")
  2017-09-29 17:04 [C++ Patch] PR 68754 ("Explicitly defaulted constexpr assignment operator fails to compile") Paolo Carlini
@ 2017-09-29 19:12 ` Nathan Sidwell
  0 siblings, 0 replies; 2+ messages in thread
From: Nathan Sidwell @ 2017-09-29 19:12 UTC (permalink / raw)
  To: Paolo Carlini, gcc-patches; +Cc: Jason Merrill

On 09/29/2017 10:04 AM, Paolo Carlini wrote:
> Hi,
> 
> the main issue, a C++14 rejects-valid, is already fixed in trunk, and a 
> while ago I added a testcase for that. However, Andrew noticed that in 
> C++11 mode we emit redundant and also a bit puzzling diagnostic (ending 
> with one of those annoying "... because:" and nothing after which 
> unfortunately we emit in some other cases too). Comparing to, eg, clang 
> too, I think we can make progress by simply returning early after the 
> first hard error. Also, as an additional tweak, we might replace the 
> second error with an inform, per the usual scheme. Tested x86_64-linux.

Looks good, thanks.

nathan

-- 
Nathan Sidwell

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-09-29 19:12 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-29 17:04 [C++ Patch] PR 68754 ("Explicitly defaulted constexpr assignment operator fails to compile") Paolo Carlini
2017-09-29 19:12 ` Nathan Sidwell

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).