[C++ Patch] Adjust one more error message to use rich_location::add_range

[C++ Patch] Adjust one more error message to use rich_location::add_range

[Paolo Carlini]

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

Hi,

I was double checking my pending patch and going through the errors we 
emit in decl.c and elsewhere about thread_local and __thread and noticed 
another place, in parser.c, where using rich_location::add_range seems 
natural. Note, we could in principle swap location and 
decl_specs->locations[ds_thread] in the error basing on the gnu bool and 
ensure that the caret always points to __thread. All in all, I don't 
think it's worth it...

Thanks, Paolo.

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


[-- Attachment #2: CL_locs_11 --]
[-- Type: text/plain, Size: 315 bytes --]

/cp
2018-07-02  Paolo Carlini  <paolo.carlini@oracle.com>

	* parser.c (set_and_check_decl_spec_loc): Use rich_location::add_range
	in error message about __thread and thread_local at the same time.

/testsuite
2018-07-02  Paolo Carlini  <paolo.carlini@oracle.com>

	* g++.dg/diagnostic/thread-thread_local.C: New.

[-- Attachment #3: patch_locs_11 --]
[-- Type: text/plain, Size: 1646 bytes --]

Index: cp/parser.c
===================================================================
--- cp/parser.c	(revision 262300)
+++ cp/parser.c	(working copy)
@@ -28377,12 +28377,15 @@ set_and_check_decl_spec_loc (cp_decl_specifier_seq
       else if (ds == ds_thread)
 	{
 	  bool gnu = token_is__thread (token);
+	  gcc_rich_location richloc (location);
 	  if (gnu != decl_specs->gnu_thread_keyword_p)
-	    error_at (location,
-		      "both %<__thread%> and %<thread_local%> specified");
+	    {
+	      richloc.add_range (decl_specs->locations[ds_thread], false);
+	      error_at (&richloc,
+			"both %<__thread%> and %<thread_local%> specified");
+	    }
 	  else
 	    {
-	      gcc_rich_location richloc (location);
 	      richloc.add_fixit_remove ();
 	      error_at (&richloc, "duplicate %qD", token->u.value);
 	    }
Index: testsuite/g++.dg/diagnostic/thread-thread_local.C
===================================================================
--- testsuite/g++.dg/diagnostic/thread-thread_local.C	(nonexistent)
+++ testsuite/g++.dg/diagnostic/thread-thread_local.C	(working copy)
@@ -0,0 +1,13 @@
+// { dg-options "-fdiagnostics-show-caret" }
+// { dg-do compile { target c++11 } }
+
+thread_local __thread int a;  // { dg-error "14:both .__thread. and .thread_local. specified" }
+/* { dg-begin-multiline-output "" }
+ thread_local __thread int a;
+ ~~~~~~~~~~~~ ^~~~~~~~
+   { dg-end-multiline-output "" } */
+__thread thread_local int b;  // { dg-error "10:both .__thread. and .thread_local. specified" }
+/* { dg-begin-multiline-output "" }
+ __thread thread_local int b;
+ ~~~~~~~~ ^~~~~~~~~~~~
+   { dg-end-multiline-output "" } */

Re: [C++ Patch] Adjust one more error message to use rich_location::add_range

[Jason Merrill]

OK.

On Mon, Jul 2, 2018 at 6:58 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
> I was double checking my pending patch and going through the errors we emit
> in decl.c and elsewhere about thread_local and __thread and noticed another
> place, in parser.c, where using rich_location::add_range seems natural.
> Note, we could in principle swap location and
> decl_specs->locations[ds_thread] in the error basing on the gnu bool and
> ensure that the caret always points to __thread. All in all, I don't think
> it's worth it...
>
> Thanks, Paolo.
>
> ///////////////
>

Re: [C++ Patch] Adjust one more error message to use rich_location::add_range

[David Malcolm]

On Mon, 2018-07-02 at 12:58 +0200, Paolo Carlini wrote:
> Hi,
> 
> I was double checking my pending patch and going through the errors
> we 
> emit in decl.c and elsewhere about thread_local and __thread and
> noticed 
> another place, in parser.c, where using rich_location::add_range
> seems 
> natural. Note, we could in principle swap location and 
> decl_specs->locations[ds_thread] in the error basing on the gnu bool
> and 
> ensure that the caret always points to __thread. All in all, I don't 
> think it's worth it...
> 
> Thanks, Paolo.

The patch looks good to me (with my "diagnostic messages" maintainer
hat on)

Thanks
Dave