named warnings & individual warning control

[Mark Mitchell]

DJ Delorie wrote:

>But this isn't really a technical issue; a good design would support
>any ID scheme.  I suspect we'll end up with a "genmessages" program to
>manage the catalog; it can do things like find the next available
>numeric mnemonic or whatever management tools make our job easier.
>  
>
I agree with this point, and your broader point that there's as much of 
a  policy component to things like message stability as there is a 
technical component.

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.  For example, 
if we C++ front end developers don't change our ways, we'll be adding 
and removing messages like mad from release to release -- and upsetting 
the users of your new technology, making the technology a lose for GCC, 
rather than a win.

Before you implement something, I think we should figure out what we 
want to do about that.  For example, maybe it makes sense to assign 
mnemonics that users can see only for messages that maintainers 
affirmatively mark as such, so that we could say "yes, we're happy with 
this message, and willing to support it for the forseeable future" 
without being locked in to some of the relatively sloppy messages we 
have now.  Part of the policy here might be that any message with a 
user-visible mnemonic (including variable messages bound together in a 
group with a single mnemonic) has to have documentation saying when it 
will be emitted and why.  That would give us a way of knowing when we 
should put a new message in that group, or not.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com