Add a __nowarn__ keyword

[DJ Delorie]

> Do we have the scope-level information available when we emit
> diagnostics from the middle-end?

Not yet.

> How do you search for the current state given a scope?

Yet to be decided.

> Also, it is not clear to me how the scope of a pragma is defined by
> its location.

It's not, you wouldn't use pragmas for scoped changes.

> You may have several contradicting pragmas at file-scope
> (set to ignore, then restore), how you lookup the status in that
> case?

Whatever was in force at that time, which may be undefined for
pragmas.

> As Gabriel, I am a bit confused by what you want to achieve with the
> proposed push/pop.

Adding push/pop was a trivial change to the pragma handler.  It exists
as an example of how to use the save/restore state tree code in
diagnostics.c.  The same save/restore API can be used to keep track of
the diagnostic state for other purposes besides pragmas, like gcc's
__extension__.

> 2. DJ wants a header with stricter diagnostics that preserves the
> initial state and restores it at the end of the header
> 
> #pragma GCC diagnostics error "-Whatever"
> #pragma GCC diagnostics error "-Whatever2"
> typical things within a header
> #pragma GCC diagnostics restore "-Whatever"
> #pragma GCC diagnostics restore "-Whatever2"

That assumes that there's a restore, and that it restores to the right
place (what if other headers have made global changes?)

> Yes, a simple #pragma GCC diagnostics restore may be shorter for
> case 2 when you have hundreds of pragmas. It will mean "undo all
> changes up to the previous pop/save operation or the initial
> state". But I think it will be a bit expensive operation when the
> user can simply do copy + paste + s/error/restore/

Did you look at my patch?  A restore is a simple pointer assignment,
nothing more.

Plus, push/pop can be properly nested, whereas change/restore cannot,
unless you define "restore" as "pop" in which case you might as well
call it that.