[warnings] tagging warnings about options themselves

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| DJ Delorie wrote:
| >>>1. If we can get to the point where every warning() call has an
| >>>OPT_*, then we can change warning() to *require* an OPT_* and then
| >>>we've locked in the new system - nobody could then add new
| >>>warnings without being able to control them.  I was pondering a
| >>>catch-all option to avoid an explosion of options, messy but
| >>>effective.
| >>
| >>This is an internal issue, affecting us as developers; it's not an
| >>argument for changing the external interface of the compiler by
| >>adding a new -Woption.
| > I'm OK with an internal-only OPT_* value, but I can't think of a way
| > to stop developers from using it only because they're too lazy to
| > think about which other OPT_* values might be appropriate.
| 
| I don't object to an internal-only OPT_ value.
| 
| What I'm less keen on is a new command-line -Wno-options switch.  I've
| never seen that in any other compiler.  We'd have to decide whether
| -Wno-options applies to warnings that would be issued based on options
| preceding -Wno-options.  It just seems needless to me...

We've gotten mutliplication of options; but we've gotten no plan for
testing consistency of the myraid of options.  This is not just a
remark about the -W* options; it is a general remark.  However, the
new -W* thingy just exhacrebates the issue. 

-- Gaby