This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: named warnings & individual warning control

DJ Delorie wrote:

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

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

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

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,
however ugly.

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, etc.

Mark Mitchell
CodeSourcery, LLC
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]