This is the mail archive of the
mailing list for the GCC project.
Re: named warnings & individual warning control
DJ Delorie wrote:
I did provide an implementation way back when. I'm not saying it was a
great implementation, but it did work; it was in the tree for less than
24 hours before Jason yanked it back out. At that time, the policy
decision was "we don't want this feature".
That means that before you check in your patch you should get policy
buy-in from the various maintainers and/or the SC. Otherwise, you'll
have provided technology that users will expect us to use in a
particular way, but that we may fail to use in that way.
I agree in principle, but as I have a limited amount of time allocated
to this, I would like to proceed with the implementation - and perhaps
leave the pragmas disconnected for now - to make the best use of my
time. Centralizing message processing, at least without the new
pragmas, does not itself add user-visible functionality but does allow
for more control over policies. I would like to be allowed to
implement the new code, assuming we agree on the issues that affect
its design, at least in parallel with policy discussions.
(My motivation here is to try to avoid what usually happens with this
issue - it get bogged down in policy and never actually gets
implemented. IMHO having an implementation that lets us implement a
policy, would get us *to* that policy faster.)
The risk is that people often end up doing:
1) I don't have much time, so I'll implement something first.
2) Now I have an implementation, so I'm very resistant to changing the
3) Also, since I have an implementation, I really want it to be checked
in; I don't want to have maintain this code myself.
I think every major GCC contributor, myself included, is guilty of
having done this at least once.
Then, we are presented with the choice of (a) alienate a prized
contributor, and eschew functionality which probably does something
useful, or (b) accept code that may or may not be ideal, and may or may
not fit well with overall direction.
I do think we learn a lot from implementation, and nobody's going to
stop you from implementing stuff, but in this case the implementation is
going to be relatively mechanical (my patch took a couple of days, for
example). If there's no buy-in from maintainers, then we haven't gained
much over the current situation.
By definition, ALL messages would have a user-visible mnemonic,This is the kind of thing I think is important to decide.
The problem, in my mind, is that as soon as you provide the mnemonic,
people will want and expect it to be stable, no matter what else you
tell them. From a technical point of view, you can say "well, I never
promised them that". But, from a marketing/support point of view,
you've now got a whole new can of worms. The current system, at least,
does not make any false promises.
I think that this was the worst thing about my patch, although I don't
remember people complaining about that aspect of it. Because I assigned
numbers to all messages, and made them all visible, and all
controllable, I'd implicitly promised the user consistency that we
probably couldn't deliver.
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,