Re: Add a __nowarn__ keyword

[DJ Delorie <dj at redhat dot com>]

> DJ, over here:
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00538.html you said:
> "We don't really support changing the diagnostics *after* you start
> defining functions.  If that happens to work at all, it's only by
> coincidence, especially with file-at-a-time optimizations and tree
> inlining."

Yes.  That's still the case, because warnings generated after parsing
is complete will always use the state of the pragmas at the end of the
file, not at the point where the function was defined.

Thus, a warning may be generated for line X that doesn't respect what
you'd think the pragmas are set for at line X.

> I expect that for the new push/pop interface to be useful, we'll
> need to support multiple uses and allow them to occur midway through
> the file.

The tricky part is keeping track of *what* state is in effect for a
given function/tree/rtl, so that the right warning state is used.
Additionally, the diagnostics API may need to be updated to pass the
chosen classification state.  Otherwise, we just keep restoring state
as needed.  It could get messy.

Perhaps we could swap state whenever we change cfun ?  Still won't
work for inlined functions, though, as I've said before.

> Do you expect this to be supported now?

Expect?  No.  I'm adding this mechanism because it's easy, and may
*happen* to be useful to wrap functions/headers/whatnot so that at
least parse-time warnings *may* be controlled that way.

Also, it may be the basis for future work that keeps track of the
state more reliably, or for small hacks that need to temporarily
change the warning state for some reason.

I'm certainly not going to volunteer to make sweeping changes to the
MI code to keep track of state for every tree node, rtl, or whatever.