This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: named warnings & individual warning control
On Tue, 22 Jun 2004, DJ Delorie wrote:
> 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
(a) implements the language (something the C++ standard is rather more
explicit than the C standard that an implementation actually has to do)
and (b) considers in the circumstances whether there might be anything to
diagnose at all.
> Bonus: -std=c90 enables some things as errors and some as warnings,
> but a -Wc90 would enable them all as just warnings (and -Ec90 would
> enable them all as errors).
-std=c90 shouldn't cause errors. It should just fix a limited number of
cases of default nonconformance as regards valid code, e.g. trigraphs
(while -pedantic also shouldn't cause errors but should cause warnings for
invalid code). There are bugs but such tend to be hard cases, e.g. where
getting a warning with -pedantic involves generating different trees for
the code rather than simply checking pedantic at the right time.
-Wc90 is meant to be analogous to -Wtraditional, and warn about
differences between C90 and C99 (which works both ways round). The
pedantic && !flag_isoc99 cases are the largest group, and the easiest to
handle (all have the same logic, pedantic && !flag_isoc99 implies pedwarn,
otherwise -Wc90 implies warning, subject to override for the individual
message), but the cases of features removed in C99 should also go in
-Wc90, and others may need their own special code as for -Wtraditional.
> > 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.)
> > -Wwrite-strings for C changes the type of string constants rather than
> > enabling specific warnings.
>
> 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.
> 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);
}
(including any catalog specifications) look like?
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 -
I don't know the performance cost of calling it otherwise in case of
individual warnings being enabled. And the status_warning code was to
handle validation of printf formats for expanding the built-in function;
this currently isn't used (and so probably shouldn't stay in the tree in
the vague possibility of future use), the code using it having been
removed by <http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02011.html> (see
discussions from there on how it might be used in future); note that the
code using it set pedantic in order to fix the behavior of the checking;
but it might be worth considering how such usage of this code would fit in
with a new diagnostics scheme.
> > * Errors (not generally disablable, we don't try to generate
> > sensible code in their presence).
>
> Split these into errors that gcc can recover from, and those it can't.
> Recoverable errors should be controllable. IMHO it's OK to have no
> control over unrecoverable errors.
Many are recovered from by setting something to error_mark_node. The
truly unrecoverable ones use fatal_error.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)