This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Named warnings
Joseph S. Myers wrote:
On Thu, 23 Jan 2003, Stan Shebs wrote:
It may also be that a single kind of warning will be displayed using
several different messages depending on context; if there is no
plausible reason for enabling one message but not the others, then
they can be combined into a single named warning. (Since this sort of
merging defeats the purpose of individual control, it should be
uncommon.)
This needs a better definition of what counts as the same or different
warnings. (And some users will want finer control over certain instances
of a particular warning only - for example, removing pedantic format
warnings for %m only but not for other non-ISO-C formats. So does the
warning for a format feature not in ISO C count as one warning with one
name, or many?)
I think those details still have to be up to the judgment of the GCC
developer. Thinking ahead to implementation, it might be a good approach
to do this with a sort of on-demand recursive subdivision - lump all
non-ISO-format warnings together initially, then break them out if the
need arises. You could even start with a -Wmisc that enables all
warnings that do not currently have a separate warning flag, start
subdividing from there. :-)
For all of these extensions, not much additional documentation will be
needed, since it should suffice to document -Wfoo as always, and then
That's lots of additional documentation - detailing all of the hundreds
(maybe thousands - gcc.pot contains 4500 messages though many are hard
errors) of separate warning options. (And testcases for all of them
should ideally be added in the process, I'm sure there are many warnings
that aren't exercised by the testsuite at all at present.)
That's certainly my #1 implementation consideration - how to get there
incrementally. One of the things I'd want to set up would be some
kind of auditing script that anybody could run to see how far along
things are. New warning controls should be made so they're an easy
bit for newbies to add too.
If warnings get reorganised so that the available warning options change,
and warning options formerly available no longer have a meaningful
equivalent, what happens to users specifying those options? (E.g., big
changes such as the new C++ parser are likely to change things enough that
various old warnings have only vague equivalents after the change.)
I would hope that these are rare. After all, you're talking about a
user-advertised feature that went away because the compiler internals
changed, which is kind of a poor practice. Sociologically, I expect
that this will make implementors think a little harder about whether
a particular warning ought to be dumped out in the first place.
Do warnings for target attributes, built-in functions, etc., get
target-specific warning-control options?
Yep. They could written as -mWfoo or -Wmfoo. :-) But seriously, the
implementation will need to be sufficiently declarative that a target
can drop in a set of target-specific warnings, check that they don't
conflict with generic warnings, etc.
One thing not mentioned: a -W option to output warnings with their
individual names, so someone can use -Wall -Wwarning-names to see the name
of the one specific -Wall warning they want to disable. (I don't think we
want warning codes cluttering output by default.)
That's a really good idea, thanks! That will save users from a round of
hunt-through-the-manual because they can't remember which messages
go with which warning flags.
Stan