RFC: Named warnings

[Stan Shebs <shebs at apple dot com>]

This RFC proposes a uniform system for handling GCC's warnings, based
on the use of names to distinguish every type of warning.  A uniform
system would make every one of GCC's warnings individually
controllable, and enable the use of pragmas and/or attributes to
control warnings within a translation unit.  The following paragraphs
focus on requirements for user-visible behavior - once there is
agreement on the desired behavior, we can then consider how best to
implement.

One of GCC's strengths is the number and variety of its warnings,
which help users by alerting them to possible mistakes in their code,
even for code that is technically correct.  However, GCC's system of
warnings has evolved in a somewhat haphazard fashion.  While most
warnings can be enabled and disabled with a -Wfoo flag, others are
unconditional (such as most warnings relating to attributes), while
others are tied to generic options such as -pedantic, which have other
consequences and can thus be a problem to use.

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.

As part of this individual control, each warning will get a unique
name, which consists of an alphanumeric string plus hyphens.  For
existing warnings with controls in the form of -W flags, the names
will correspond to the flag names, so -Wfoo-bar controls the warning
named "foo-bar".  There are no limits on the lengths of warning names,
but "no-" at the beginning of a name is reserved to indicate the
negation of the warning.  ("no-" would not be part of any warning's
name, irrespective of the warning's default value.)

It may still be that some warnings are composites, as with -Wunused,
which controls several other warnings that each have an individual
control, but this is up to the implementation.

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.)

Another frequent request for warnings is that they be changeable
within a translation unit.  Sometimes this is because a warning has
been analyzed and is known to be uninteresting in a particular
context.  Another reason is that additional optimizations are possible
within a translation unit, as is visibility control for private
symbols, so it's undesirable to break one into several units just so
that a -Wno-foo can be applied to a part of the original translation
unit.  Last and perhaps least :-), this feature is provided by
competing compilers, and is expected by users bringing code over from
other platforms.

The obvious way to add fine-grained control is with attributes.  For
instance,

int fn() __attribute__ ((warning ("no-sign-compare", "switch")))
{
 ...
}

would say to warn about any missing cases in switch statements but not
any signed/unsigned conversions within the scope of fn.  The
attributes act as temporary overrides to the global values as
prescribed by compiler defaults and -W flags.  So that warnings' names
need not be constrained by language syntax, they should be expressed
as strings.

Attributes are useful for limiting effect to single functions or
variables, but are unduly repetitive for long files with many
functions and variables.  Pragmas would work better then, as in

#pragma GCC "no-sign-compare" "switch"
...
#pragma GCC "sign-compare" "switch" "missing-prototypes"

which disables signed/unsigned warnings and enables switch case
warnings, then later re-enables the sign warning and also the missing
prototype warning, but with no further effect on switch case warnings.

The effect of each pragma is a one-way change to the warnings listed.
(It would be possible to have warning control pragmas with a push/pop
behavior, but this seems excessive complicated, both to implement and
to use correctly.)

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.

For all of these extensions, not much additional documentation will be
needed, since it should suffice to document -Wfoo as always, and then
to direct users to remove the "-W" in order to know what names are
available for warning attributes and pragmas.

Stan