Re: RFC: Named warnings

[Neil Booth <neil at daikokuya dot co dot uk>]

Hi Stan,

Stan Shebs wrote:-

> So as a first step I propose that all of GCC's warnings be made
> individually controllable, and that all future warnings always get a
> control when they are added to the compiler.

I support this in principle, but I think making each warning
controllable is too fine-grained.  For example, the C parser work I'm
doing emits many quite different warnings to the current parser.

o What do we do when a warning moves, disappears or becomes different?
o I agree with Matt that push / pop is necessary
o I think consideration should be made to turning many current warnings
  into errors.  This will reduce the number of warnings we need to
  control.  My experience writing my C parser is that I've made many
  things that were warnings into errors.  Sure, you can warn and do
  the obvious thing to accept the translation unit, but I tend to
  lean towards making errors of things that are easily avoided
  and not stylistic.  e.g. "inline int x;" is currently a warning,
  and IMO should be an error.  Existing warnings like the struct cpp_reader
  one in prototypes should of course remain a warning, as there is
  nothing actually syntactically or semantically incorrect about the usage.
o I'm a little concerned about how we do switch parsing.

FWIW I intend to create a lang-specific file "opts.def", a top-level
opts.def and a target-specific opts.def that are line-oriented awk-parsable
files containing the switches, help text and other relevant details
details about each switch (as is currently done in a big table in
c-opts.c, but with no help text).  Each line would be a field, and
each option a record, separated by a blank line.

cat-ting all these together at build time into an awk script that sorts
them and generates a header containing an enumeration, and a file with a
data table should be straight forward.  In this way, we can finally have
unified option handling outside the driver, with all options handled in
one place (and passed down to front-ends or back-ends via hooks).
The option handling code currently in c-opts.c is already generic enough
to do everything we need I think.

The only reason I've not started on this is I'm still trying to get
a copyright disclaimer out of my employer.  The changes should be fairly
straight-forward to do, just quite a lot of work.

> The obvious way to add fine-grained control is with attributes.  For
> instance,
> 
> int fn() __attribute__ ((warning ("no-sign-compare", "switch")))
> {
>  ...
> }

What I worry about here is are the attributes part of the function
type?  Or just something invisible to normal C rules on the decalarator?

> Finally, while -Werror is a useful option, it's difficult to use
> reliably in portable software (as witness GCC's own recent travails)
> because it affects all enabled warnings.  It just so happens that
> -Efoo is not used for anything now, so I propose that -Efoo be defined
> to work equivalently to -Wfoo -Werror for warning "foo" only.  There
> are complexities with random combos like -Wfoo -Eno-foo -Wno-foo
> -Efoo, and these need more thought before implementing.

If we do this, the option handling code could special-case the 'E' and
share the rest of the code, like it currently special-cases the "no-"
without doubling the number of switches.

Neil.