This is the mail archive of the
mailing list for the GCC project.
Re: named warnings & individual warning control
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
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
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
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.