Re: named warnings & individual warning control

[Stan Shebs <shebs at apple dot com>]

Mark Mitchell wrote:

> Personally, I'd oppose any patch to implement this feature (including 
> my original one) if we don't have a policy statement about how the 
> feature is going to be used.  I think that implementing this feature 
> in a way that is useful to people is going to require a lot more 
> discipline from those of us that are front end maintainers, in 
> particular, and I think we need to know how we're going to do that.  
> Now, from a technical point of view, if you put all the messages in a 
> catalog, and tagged them with their existing warning categories -- but 
> didn't change the user interface at all -- that would just be a 
> technical patch, and we could consider it on its technical merits  -- 
> is it easier/harder to maintain, etc.
Hard to know where to jump into the flurry, so I'll start from the
end. :-)

I think there's some disconnect between how much people expect
things to change. For example, my trusty 1.32 manual mentions
-Wreturn-type as working basically the same as today, so we have
some warnings whose names are completely stable, and it won't be a
problem to state that they will continueunchanged for another 15
years.

Conversely, there are some warnings in the C++ frontend that seem,
shall we say, "ephemeral". :-) It would be unreasonable to expect
that they remain forever, for instance if they are warning about
limitations of the compiler more than about faults in the source
code.

So the policy ought to be flexible enough to allow some warnings
to be removed without much ado, and there should be an
unrecognized-warnings warning (off by default) for those who want
to hear about warnings that are no longer in the compiler. In any
case, we should agree on policy details now, since that will help
other people to know how to contribute once DJ's cycles run out.

Stan