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]

> "Manuel" == Manuel López-Ibáñez  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]

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  
Tom Tromey  

* 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

[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

[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
jos...@codesourcery.com