Re: [PATCH 2/5] c_diagnostic_ignored_function hack

Re: [PATCH 2/5] c_diagnostic_ignored_function hack

[Manuel López-Ibáñez]

> This patch makes it possible to suppress the function-name display in
> a straightforward way: it adds a new global which the plugin can set
> to declare the name of the dummy function.
>
> This patch seems like a bit of a hack, but there didn't seem to be a
> notably cleaner approach.

Can't you override the diagnostic_starter() in your plugin? This way
you can even customize it to print "gdb" in the prefix (if you wish to
provide a custom prefix). If that is possible, that seems way cleaner.
If not, I wonder why not.

Otherwise, why not override the lang_hook itself? This way the plugin
can provide its own lang_hook so that your proposed
c_print_error_function lives in the plugin itself.

I'm probably missing something obvious here.

Cheers,

Manuel.

Re: [PATCH 2/5] c_diagnostic_ignored_function hack

[Tom Tromey]

>>>>> "Manuel" == Manuel López-Ibáñez <lopezibanez@gmail.com> writes:

Tom> This patch makes it possible to suppress the function-name display in
Tom> a straightforward way: it adds a new global which the plugin can set
Tom> to declare the name of the dummy function.

Manuel> Otherwise, why not override the lang_hook itself? This way the plugin
Manuel> can provide its own lang_hook so that your proposed
Manuel> c_print_error_function lives in the plugin itself.

I've changed my local tree to use this approach, as it seemed simplest.
Thanks for the suggestion.

Tom

Re: [PATCH 2/5] c_diagnostic_ignored_function hack

[Tom Tromey]

Joseph> I'd say this global actually belongs somewhere in the
Joseph> diagnostic_context (i.e., instead of the
Joseph> diagnostic_context_auxiliary_data (DC) actually being a tree as
Joseph> it is at present, it should point to a structure with whatever
Joseph> extra information clients wish to use to control aspects of
Joseph> diagnostic reporting).

We dropped this patch from the series and instead the diagnostic stuff
is all handled in the plugin itself.  You can see it in the new patch #5.

Tom

Re: [PATCH 2/5] c_diagnostic_ignored_function hack

[Tom Tromey]

Jeff> BTW, didn't see patch #5 of the series.

Maybe it was too big.
I will try to resend it compressed.

Tom

Re: [PATCH 2/5] c_diagnostic_ignored_function hack

[Jeff Law]

On 05/16/14 09:26, Tom Tromey wrote:
> In the typical case, when compiling a snippet of user code, gdb wraps
> the user's text in a dummy function.
>
> It's somewhat odd for users if an error in their code is mentioned as
> coming from this dummy function.
>
> This patch makes it possible to suppress the function-name display in
> a straightforward way: it adds a new global which the plugin can set
> to declare the name of the dummy function.
>
> This patch seems like a bit of a hack, but there didn't seem to be a
> notably cleaner approach.
>
> 2014-05-16  Phil Muldoon  <pmuldoon@redhat.com>
> 	    Tom Tromey  <tromey@redhat.com>
>
> 	* c-lang.c (c_diagnostic_ignored_function): New global.
> 	(c_print_error_function): New function.
> 	(LANG_HOOKS_PRINT_ERROR_FUNCTION): Define.
> 	* c-lang.h (c_diagnostic_ignored_function): Declare.
Just a few nites.

In c-lang.c, please use the old C-style comments.  If for no other 
reason than it's consistent with all the other nearby code.   Consider 
using non-NULL when referring to pointers rather than non-zero.  */

Otherwise OK.  Please wait to install until the entire kit is approved.

BTW, didn't see patch #5 of the series.

jeff

Re: [PATCH 2/5] c_diagnostic_ignored_function hack

[Joseph S. Myers]

On Fri, 16 May 2014, Tom Tromey wrote:

> In the typical case, when compiling a snippet of user code, gdb wraps
> the user's text in a dummy function.
> 
> It's somewhat odd for users if an error in their code is mentioned as
> coming from this dummy function.
> 
> This patch makes it possible to suppress the function-name display in
> a straightforward way: it adds a new global which the plugin can set
> to declare the name of the dummy function.
> 
> This patch seems like a bit of a hack, but there didn't seem to be a
> notably cleaner approach.

I'd say this global actually belongs somewhere in the diagnostic_context 
(i.e., instead of the diagnostic_context_auxiliary_data (DC) actually 
being a tree as it is at present, it should point to a structure with 
whatever extra information clients wish to use to control aspects of 
diagnostic reporting).

-- 
Joseph S. Myers
joseph@codesourcery.com

[PATCH 2/5] c_diagnostic_ignored_function hack

[Tom Tromey]

In the typical case, when compiling a snippet of user code, gdb wraps
the user's text in a dummy function.

It's somewhat odd for users if an error in their code is mentioned as
coming from this dummy function.

This patch makes it possible to suppress the function-name display in
a straightforward way: it adds a new global which the plugin can set
to declare the name of the dummy function.

This patch seems like a bit of a hack, but there didn't seem to be a
notably cleaner approach.

2014-05-16  Phil Muldoon  <pmuldoon@redhat.com>
	    Tom Tromey  <tromey@redhat.com>

	* c-lang.c (c_diagnostic_ignored_function): New global.
	(c_print_error_function): New function.
	(LANG_HOOKS_PRINT_ERROR_FUNCTION): Define.
	* c-lang.h (c_diagnostic_ignored_function): Declare.
---
 gcc/c/ChangeLog |  8 ++++++++
 gcc/c/c-lang.c  | 22 ++++++++++++++++++++++
 gcc/c/c-lang.h  |  4 ++++
 3 files changed, 34 insertions(+)

diff --git a/gcc/c/c-lang.c b/gcc/c/c-lang.c
index 97c0443..e563813 100644
--- a/gcc/c/c-lang.c
+++ b/gcc/c/c-lang.c
@@ -35,6 +35,26 @@ along with GCC; see the file COPYING3.  If not see
 
 enum c_language_kind c_language = clk_c;
 
+// If non-zero, this names a function which should not be reported in
+// a diagnostic.  This is used by the gdb plugin to avoid showing the
+// generated function name to the user.
+const char *c_diagnostic_ignored_function;
+
+// An implementation of the print_error_function langhook that
+// respects C_DIAGNOSTIC_IGNORED_FUNCTION.
+static void
+c_print_error_function (diagnostic_context *context, const char *file,
+			diagnostic_info *diagnostic)
+{
+  if (c_diagnostic_ignored_function != NULL
+      && current_function_decl != NULL_TREE
+      && DECL_NAME (current_function_decl) != NULL_TREE
+      && strcmp (IDENTIFIER_POINTER (DECL_NAME (current_function_decl)),
+		 c_diagnostic_ignored_function) == 0)
+    return;
+  lhd_print_error_function (context, file, diagnostic);
+}
+
 /* Lang hooks common to C and ObjC are declared in c-objc-common.h;
    consequently, there should be very few hooks below.  */
 
@@ -44,6 +64,8 @@ enum c_language_kind c_language = clk_c;
 #define LANG_HOOKS_INIT c_objc_common_init
 #undef LANG_HOOKS_INIT_TS
 #define LANG_HOOKS_INIT_TS c_common_init_ts
+#undef LANG_HOOKS_PRINT_ERROR_FUNCTION
+#define LANG_HOOKS_PRINT_ERROR_FUNCTION c_print_error_function
 
 /* Each front end provides its own lang hook initializer.  */
 struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
diff --git a/gcc/c/c-lang.h b/gcc/c/c-lang.h
index 7fcf333..022206f 100644
--- a/gcc/c/c-lang.h
+++ b/gcc/c/c-lang.h
@@ -59,4 +59,8 @@ struct GTY(()) language_function {
    attribute lists.  */
 extern GTY(()) int current_omp_declare_target_attribute;
 
+/* If non-zero, the name of a function whose name should not be
+   reported in a diagnostic.  */
+extern const char *c_diagnostic_ignored_function;
+
 #endif /* ! GCC_C_LANG_H */
-- 
1.9.0