named warnings & individual warning control

[DJ Delorie]

> This is indeed a huge problem, since these mnemonics end up all over the
> source and will cause maintenance problems, both for GCC and for user 
> code.

I've been intentionally avoiding the problem of decorating user code ;-)

One thing we all seem to agree on is that source-controlled changes
need a save/restore stack (aka push/pop).  I suspect we need some way
of remembering the state at some point in the parsing, for if the
language decides to keep track of that to make message reporting more
accurate (for example, tagging a variable at parse time, to know which
messages to report when it's used).  At this point I'm not going to
try to imagine how the languages would take advantage of that.

Initially, implementing a simple pragma to effectively override -W
options is probably all we can expect of a first pass.  I would be
happy with a limitation that the user should do these pragmas early in
their source and not define what happens if you intersperse them with
code, but we should allow for the language to apply these controls in
various scopes as well (for example, a _Pragma within C's block scope).

> In essence this allows suppressing all warnings in very specific
> places, instead of adding fine grained warning control that remains
> in effect throughout the compilation unit.

My idea would allow for both, if the language supported it, but would
not implement both at first.

> Warnings change quite often and are split or merged at times, so it
> will be hard to keep mnemonics stable enough to not require source
> changes.

I would argue that, for some gcc users, having to edit the list of
warning controls for each gcc release is well worth the benefits from
such a feature.  As mentioned previously, consider a company that
upgrades gcc infrequently, has a policy of requiring -Werror, yet
encounters a situation where they can't work around a warning.  They
won't care if it's HARD to fix, only that it's POSSIBLE to fix.