Re: RFC: Named warnings

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

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

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

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

Do warnings for target attributes, built-in functions, etc., get 
target-specific warning-control options?

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

-- 
Joseph S. Myers
jsm28@cam.ac.uk