named warnings & individual warning control

[DJ Delorie]

> I still don't see the "only need review", or the value of "standards
> compliance reports" from genmessages.

The report I'm thinking of is like "the following conditions are
reported when C99 compliance is requested..."  I suppose I don't know
how useful that would be, but it's something that's easy to generate
from a central database.

> > But -std in conjunction with -pedantic might, yes?  Can we say for
> 
> That would be a bug, again.  -pedantic should add warnings only.  It
> shouldn't add errors (that's the job of -pedantic-errors), and it
> shouldn't remove warnings; at present, it might well do both

Not sure if that makes things easier or not.

> > A genmessages could also be used to assist whoever is hand-generating
> > the test cases, by (for example) checking to see if all the available
> > options have been represented in the available test cases.
> 
> That at least would make sense - provided we do properly avoid regressions
> in testsuite coverage (once all diagnostics are tested, we don't allow new
> ones without tests).

Hmmm... one of the tests could be to audit the other tests.  Failure
to add a coverage test would cause a regression.

> I suspect changing such an option (written flag_const_strings; and note
> that for C++, -Wwrite-strings sets warn_write_strings instead, which does
> something different in language-standard terms) in the middle of a source
> file might cause more trouble than changing those that do simply condition
> warnings.

Yeah, that was one of the tricky bits with ANY kind of in-source
control.  What to do once parsing starts.

> But in the above, the if is keeping much of the "Do we care?" in the
> source; the pedantic check has moved, but a user might want the C99
> language but with warnings about features not in the C90 library, using a
> new compiler with an older library; the condition "%zu in format string"  
> still exists even if the condition "format not in current standard"  
> doesn't.  This can be done, by putting a check of -Wc90 in the definition
> of C_STD_VER, but it's still "Do we care?" logic in the source.  Not that
> I think you can necessarily do better at moving all this logic
> otherwise....

The only alernative is to just call 

   status_message (status, MSG_format_unsupported_std, 
 	          C_STD_NAME (fci->std), format_char, fki->name);

And let the catalog decide if that message is of interest or not.
That would mean, for formatting, that we somehow have to elaborate on
which format char we're talking about, and that's tricky.  Well,
trickiER at least.  Hence my original plan that sometimes you still
have to do the logic in the source with message_p() instead of simply
calling message().

> Which is a pedwarn rather than a mandatory error anyway, and comes from
> cpplib.  Is there any proposal for including cpplib in this scheme?  It
> could reasonably be dealt with later, but I don't think users would care
> for the distinction about what code is generating the messages.

What does cpplib do *now*?  There must be some kind of callback
already, or else messages won't go through the usual channels we
already have.  This does complicate things, though.