Re: RFC: Named warnings

[Mark Mitchell <mark at codesourcery dot com>]

--On Thursday, January 23, 2003 05:06:16 PM -0800 Stan Shebs 
<shebs@apple.com> wrote:

> As part of this individual control, each warning will get a unique
> name, which consists of an alphanumeric string plus hyphens.
Overall, I think your proposal is fine, and I like the ideas about
attributes.

I think the one sentence quoted above is a mistake.  I know people
don't like numbers, but I think numbers are actually better here.

Some of the objections have been:

- The numbers will change.

 But, actually, they won't.  It's not hard to keep from changing
 them, and I've worked on multiple compilers that had no trouble
 keeping the numbers the same.

- The numbers aren't mnemonic.

 True, but how mnemonic are the literally hundreds of warnings in
 the C++ front end going to be as foo-bar-baz strings?

 The way people actually use this feature in other compilers is like
 this:

 (1) Run the compiler.
 (2) Look at the warnings.
 (3) Note that a particular warning isn't making sense for their
     code.
 (4) Insert a #pragma/attribute/comment to turn it off.

 Since steps 3/4 come together, something like:

   warning [123]: You're a moron, Mark.

 is easily dealt with; you copy the "123" into your code.

 I'm not sure that:

   warning [moron-mark]: You're a moron, Mark.

 is going to be very friendly if that foo-bar-baz string gets long,
 and if it's not present then it's a pain in the neck to find the
 supposedly mnemonic string.

So, in favor of numbers:

- They're shorter.

- They're language-independent.

 GCC could have a manual section, like many other compilers, listing
 all the warnings in numberical order with a description of what each
 warning (and error) is about.

In any case, it would be a good idea to include errors in your scheme.

Also, some errors should have the ability to be turned into warnings
(that's what -fpermissive does in C++, for example), and all warnings
should have the ability to be turned into errors.  It makes sense
to name/number *all* diagnostics, if for no other reason than
easier documentation in the manual.

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com