This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Named warnings
- From: Stan Shebs <shebs at apple dot com>
- To: Matt Austern <austern at apple dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, DJ Delorie <dj at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 24 Jan 2003 15:46:33 -0800
- Subject: Re: RFC: Named warnings
- References: <EE552440-2FF1-11D7-BFA6-000393B2ABA2@apple.com>
Matt Austern wrote:
On Friday, January 24, 2003, at 02:35 PM, Mark Mitchell wrote:
--On Friday, January 24, 2003 02:11:31 PM -0800 Stan Shebs
<shebs@apple.com> wrote:
I like this idea as a way of organizing things. It's more complicated,
but I think it could be a sort of layer superimposed on basic machinery;
in other words, names can be arbitrary, but if you use the hierarchical
scheme for a name, you get to ask for groups of warnings "for free".
It's also worth thinking about what you're going to do when the (English)
message changes. -Wunused-class is a mnemonic for:
warning: class `T' is unused
but if it later becomes apparent that a better way to word the error is:
warning: class `T' is defined but never referenced
That's a good argument for numeric codes instead of mnemonics.
I look at it as more of an argument for choosing eternally-meaningful
warning names. To me anyway, -Wunused-class is still preferable to
-Wclass-defined-but-never-referenced... :-)
Choosing good warning names is a little like writing headlines;
they should be short and to the point, but you can leave the full
explanation for the message itself.
What do we know about prior art for other compilers? At the
risk of stating the obvious, providing pragmas and command
line options to get fine-grain control over warnings is not
a new idea. We may as well try to learn from other people's
mistakes.
CodeWarrior has about 20-30 types of warnings, all controlled
by pragmas like "#pragma warn_unusedvar on|off|reset" for unused
variables.
Interestingly, only about half of the warnings have checkboxes in
the IDE, and the manual has to mention which warnings correspond to
IDE settings, and which can only be controlled from the source
code.
CW also tends to issue errors where GCC might try to come up
with an interpretation. So for instance it unconditionally
errors on Neil's example of "inline int x;".
Stan