Re: named warnings & individual warning control

[Mark Mitchell <mark at codesourcery dot com>]

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
mark@codesourcery.com