Re: named warnings & individual warning control

[DJ Delorie <dj at redhat dot com>]

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

> For example, maybe it makes sense to assign mnemonics that users can
> see only for messages that maintainers affirmatively mark as such,

I've already suggested the "stable" tag for messages, which allows
machine audits of policy (a cron job that verifies nothing changed
logic-wise).  Another suggestion is that warning mnemonics with
numeric suffixes be reserved for "unstable" controls, those without
numeric suffixes are "stable" controls.  For example, -Wformat is
guaranteed to have a certain definition, but within that group,
-Wformat-45 has no such guarantees.  That is also something that can
be programmatically added to any genmessages program, such as for
generating documentation or web pages from the message catalog.

> Part of the policy here might be that any message with a
> user-visible mnemonic

By definition, ALL messages would have a user-visible mnemonic,
however ugly.  IMHO that's the whole point of this project.  I think
what you refer to is a user-documented mnemonic, something which is
more official than just an arbitrary string in the sources.

(The old design assumes a small number of warning groups which are
"abused" by having each controlling many messages.  The new design
should assume maximally precise control over messages, and be "abused"
by grouping them.  We end up with the same basic groupings, but at
least the new way the user can (however painfully) control what they
need to.)

But otherwise, I agree that we need a policy for determining what's
going to be stable over time and what isn't.  I just don't think (1)
my input is that useful, and (2) it should hold up development
(deployment, maybe, but not development).