This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: named warnings & individual warning control
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