Re: named warnings & individual warning control

[DJ Delorie <dj at redhat dot com>]

> > catalog decides if it's a warning, error, pedwarn, or ignored.  That
> > also means that the folks responsible for standards compliance only
> > need review the message catalog; and perhaps a genmessages program
> > could provide standards compliance reports.
> 
> That's an interesting "only need"!  Conformance is more than just emitting
> required diagnostics and the main part must be looking at the source which

Ok, let me rephrase: assuming the code properly detects the situation
in question, whether to flag that situation as a warning or error
given a requested level of standards conformance can be determined
from the catalog.

I don't mean to say that a message catalog replaces all the code
involved in detecting these conditions, just whether or not the user
cares to see the messages.  I agree there may sometimes be cases where
additional processing is required to detect such a situation, and the
code may need to know if the relevent messages are desired in order to
do additional work to decide when to propose the message to the user.

That's why my original proto-design had both an "issue this message"
and "is this message enabled" API.  I expected that not all cases can
be deferred to the message catalog.

IMHO this becomes more obvious as we add more layers of standards.  A
given condition either exists or it doesn't exist, but whether it is
to be reported depends on which of the N standard levels we're
currently interested in, for arbitrarily large values of N.  Yes, the
developer needs to ensure that the condition is properly detected.
Which standards care about which conditions can be treated as a
separate problem, and that is what I was referring to.

> -std=c90 shouldn't cause errors.

But -std in conjunction with -pedantic might, yes?  Can we say for
sure that there will never be a single option that enables both errors
and warnings at the same time?

> > > Naturally every warning should (ideally) have tests that its default
> > > nature is right in all standard modes, and its own control mnemonic does
> > > indeed control it.  (The latter, testing all mnemonics, helps ensure the
> > > stability Mark asked for.)
> > 
> > This is an argument for machine-parsable state logic (a genmessages
> > program, for example) rather than ad-hoc in-source logic.
> 
> You mean to have a special test in the testsuite to fail if any
> diagnostics don't have their own tests?  (Since the tests for each
> diagnostic must be human-written and verified.)

Test cases will always need to be hand generated, or at least hand
audited when machine generated.  However, we can automate iterating
those test cases over various combinations of command line options and
making sure they appear when they're supposed to.  Or at least
generate a table of expected results for manual auditing.  The
permutations become unweildy.

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.

> > The message_p(MSG_writable_strings) API would be suitable.  If the
> > message is enabled, the compiler could do additional things to ensure
> > it's able to detect the case where the message is appropriate.
> 
> The "message" consists of many general messages about type incompatibility
> and discarding const, which appear as a side-effect of generating
> different trees.  Sometimes the option (which renders the compiler
> nonconforming) may cause diagnostics to disappear as well as to appear.  
> To control at point of generation you'd effectively need to build all
> trees twice, with both possible types for string constants.  The
> individual messages could be controlled, but the exact same messages
> appear for cases not involving string constants.

But, what do we do now for -Wwrite-strings?  Whatever it is, shouldn't
change.  We can still ask if -Wwrite-strings was enabled, still change
the way strings are processed, still emit messages as before (although
now *those* can be controlled too).

I don't see why any of this needs to change.  The only change I'm
suggesting is the details of how we keep track of what the user asked
for, it would only change from "if (warn_writable_strings)" to "if
message_p (MSG_writable_strings)".  And the only reason for changing
the internals is so that it supports more control in other places.

> > I prefer to discuss details by presenting code, as it's an ideal
> > language for documenting such details.
> 
> What then would example code for
> 
>   if (pedantic)
>     {
>       if (ADJ_STD (fci->std) > C_STD_VER)
>         status_warning (status, "%s does not support the %<%%%c%> %s format",
>                         C_STD_NAME (fci->std), format_char, fki->name);
>     }

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

This might be further controlled by -std=, -Wformat,
-Wformat-unsupported, -Wformat-unsupported-std,
-Wformat-unsupported-c99, etc.  Maybe even -Wformat-unsupported-d (for
%d).

The facts that the message is affected by -pedantic, is a warning, or
even is displayed, is not relevent to deciding if the condition for
that message exists.  I.e. I'm trying to separate these questions:

1. Does the condition exist?
2. Do we care?

Logic for the first must be in the sources as it is now.  Logic for
the second need not be, and IMHO should not be (because centralizing
*that* logic allows for future flexibility in message control).

> Note the macro expansions involved in ADJ_STD, C_STD_VER and C_STD_NAME.  
> And all this code is only ever called to generate warnings for -Wformat -

In handle_format_attribute would be:

	if (!message_p (MSG_format))
	  return NULL_TREE;

to bypass the whole thing if the group as a whole is disabled.

I.e. I'm accepting the fact that the user can't enable just one format
warning; they have to enable the whole group with -Wformat and then
they can possibly disable specific warnings.

> Many are recovered from by setting something to error_mark_node.  The 
> truly unrecoverable ones use fatal_error.

>From the user's point of view, a recoverable error (and thus one that
can be ignored) is one which, if ignored, produces an object file.  By
this definition, anything producing an error_mark_node is not one.
One example of an ignorable error is "source file doesn't end with a
newline".