Ping Ping Ping: [PATCH] RFA: Add a small indication to warnings that are promoted to errors

[Simon Baldwin]

On 29 January 2010 19:20, Mark Mitchell <mark@codesourcery.com> wrote:
>
> Simon Baldwin wrote:
>
> >>> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01101.html
> >>> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01197.html
>
> I'm not convinced that there's a real problem here.  If you say -Werror,
> you're telling the compiler to treat warnings as errors, and the fact
> that it then presents warnings as errors doesn't seem like that bad of
> an idea to me.


I have not suggested that -Werror no longer present warnings as
errors.  The patch does not affect this any way.

The problem's one of usability.  It's most visible when you have a
build tool or environment that enforces (or strongly defaults)
-Werror.

For developers using such a system, there is no visible difference in
gcc diagnostics for code which has defined behaviour but which gcc
considers suspicious, and for code which has undefined behaviour.
Both appear as errors, yet when working to make them go away, a
developer would benefit from knowing that the second really needs
fixing, and that the first is work to appease the draconian build
system (so perhaps they can lobby for a less draconian one).

Gcc does note at the start of diagnostics that warnings are errors,
but if there are also genuine errors present then there's no way to
guarantee a visible distinction between these and the promoted
warnings (and it is also easy to miss or read past the introductory
note).

-fdiagnostics-show-option provides a partial solution.  Unfortunately,
many warnings are not related to an option (for example 'control
reaches end of non-void function'), so adding it doesn't indicate
every promoted warning, just some of them.  The patch adds a
indication to all of them.

As an alternative, how about: if -fdiagnostics-show-option, append a
bare '[-W]' for cases where there is no more specific option
associated with the warning?  Would that be clearer?  It seems
relatively consistent with the way -fdiagnostics-show-option might be
expected to work.

>
> The interface I'd really like is to give diagnostics numbers/names so
> that it's easier for people to turn them off.  Other compilers do this,
> using, for example, "NNNNN" codes.  That would allow indexes that had
> more information about the error and what causes it.
>
> The reason I'm tying these two ideas together is that you could use
> "WNNNN" for warnings and "ENNNN" for errors, independent of -Werror.
> So, you'd get:
>
>  error: [WNNNN] <the message>
>
> If we don't want to do that, and do think that there's a problem that
> needs solving, then I think the "[was warning]" patch is better.  The
> "error: warning: ..." syntax would make me think the compiler was just
> confused.

This would be excellent, and would of course solve the whole issue.
Unfortunately, it's probably some way in the future.


--
Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ | Registered in England Number: 3977902