Re: Add a __nowarn__ keyword

["Kaveh R. GHAZI" <ghazi@caip.rutgers.edu>]

On Wed, 8 Aug 2007, DJ Delorie wrote:

>
> > If you're saying that, by design, your pragma interface only allows a
> > once-per-file setting that must come before all function definitions, then
> > it isn't suited to do what I want.  I need something that allows
> > per-statement warning silence, then reset to whatever was before, and then
> > do that as many times as necessary.
>
> Right.  The current interface has two parts: The master table of what to do
> with each diagnostic, and the #pragma to change the table.  What's missing
> are two things:
>
> 1. A chain of "what changed" with back pointers, so we can implement
>    push/pop, nested settings, and a "revert" option, and
>
> 2. A way to associate a link on that chain with a point in the program
>    in a meaningful way.  It's the "meaningful way" that was hard to
>    define back then.
>
> Anyway, item 1 is relatively easy, but not useful (or at least
> ill-defined) without completing #2.  #2 is hard.
>
> Now, if a __warn__ syntax is well-defined, perhaps we could add item
> #1 as a way to implement it?

If we go with __nowarn__ (or __warn__) I believe the syntax is well
defined since it mimics the long-standing __extension__ behavior.  It
cleanly handles the push/pop paradigm because the handler code resides in
the parser.  Any time it sees the __extesion__ or __nowarn__ token, the
parser saves the current value of the warning flag, consumes the token and
recurses parsing.  When the recursion returns, it restores the old value
of the warning flag in question and proceeds.  Simple.

One potential problem is if warnings are emitted from elsewhere than in
the parsing stage.  E.g. if a warning comes from the middle-end, then
possibly __nowarn__ doesn't get to intercept it using this mechanism.
I don't know if this occurs in practice, and if so whether it happens
enough to invalidate this approach.  It sems to work for __extension__ so
I am cautiously optimistic it'll work for __nowarn__.

Still my preference is to go with the original union-hack and avoid this
altogether. :-)

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu