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
>
> 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 still don't see the "only need review", or the value of "standards
compliance reports" from genmessages. No doubt there are advantages to
users in being able to choose which -pedantic warnings they want as
warnings, which as errors and which not at all (provided -std=whatever
-pedantic-errors continues to work, i.e. make all those required by the
standard errors). But looking at a catalog would be a tiny part of
assessing conformance; reports of the form "n messages for C90 but not
C99" seem of little use; you can look at the code and compare with the
standard; look at the standard and compare with the code and write
testcases; and run third-party testsuites as one of the potentially most
useful ways of getting a report. (On this last I've heard rumours that
C90 testsuites have been passed, rumours that they haven't, and rumours
that the licence conditions for such testsuites don't permit such
disclosures; in any case they are expensive and I have seen no such
testsuite results.) Or you can simply observe the facts for each standard
as a binary {Yes (modulo bugs), No} matter (plus summary of unimplemented
features) without reference to genmessages: C90 is not implemented
(bit-field types, constant expression constraints), C99 is not
implemented, C++98 is not implemented (export, maybe other features),
Ada95 is implemented modulo bugs (and doesn't use the core diagnostics
code), ....
> > -std=c90 shouldn't cause errors.
>
> 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 (as well as
conceivably changing code generation in some cases; at least, you get
different trees sometimes).
> 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).
> 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 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.
> 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?
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....
> 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".
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.
In general, if we make something a mandatory error now, I don't think we
should do anything suggesting a possibility of recovering from it (which
might give rise to unfortunate user expectations of future versions
supporting recovering from it as well). Instead, simply ignore any
attempt to disable such errors or turn them into warnings (no doubt they
need mnemonics, for consistency and since they might previously have been
warnings).
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)