Re: named warnings & individual warning control

[DJ Delorie <dj at redhat dot com>]

> I don't see this as a deal-breaker, but I think I'm on the other
> side of this one.

There's nothing stopping a developer from choosing a numeric mnemonic
(you get command line options like "-Wno-45681" for free ;).  The
technical problem there is managing the number space between the core,
language, and target sources.  I would argue against basing the
catalog on *numbers* (vs numeric strings) as we need to support some
form of string naming to match command line options anyway, and I'd
rather have one mechanism than two.

Basing message numbering on a message's index in a catalog would be a
nightmare.  It would be very difficult to determine the index of a
message in a flexible catalog, and merging multiple catalogs would
cause no end of sequencing pain.

What I'd like to avoid is needing to preserve the INTERNAL sequencing
of messages.  Mostly because I'd like to sort the catalog internally
so it can be scanned faster, and I'd rather not be tied to a specific
ordering.

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 would like to hide the details of formatting messages (to include
the mnemonic) inside one function, so it can be easily changed if we
decide to.  I, for one, would prefer a command line option to select a
message formatting - terse, terse with mnemonic, verbose with
mnemonic.  Regardless, such a decision should be deferrable.

> This I do see as a major issue.

I agree, I was just commenting on the perceived consensus, which is
that it is difficult to enforce sufficient consistency across releases
without severely impacting development.  However, it is not a design
decision - it's a management and documentation one.  I don't see it as
a blocker for actually doing the work.

> If you use the catalog approach, it's relatively easy to maintain
> stability of numbers or mnemonics: always add to the end of the
> catalog, and clear out -- but do not remove -- entries that you're
> no longer using in the middle.

That doesn't solve the problem, because mnemonics that used to block a
message no longer block it.

I suspect it would be useful to be able to tag a message as "obsolete"
and provide a warning that warns for obsolete messages (disabled by
default, so people can cleanly support multiple gcc versions).

In fact, supporting arbitrary tags and some flexible reporting
mechanisms is probably a good idea.  For example, a "stable" tag in
the catalog can be used to enforce stability, give it a value of "1"
for stability between major releases (3.0 to 4.0) , "2" for minor
releases (3.2 to 3.3), "3" for bug releases (3.2.1 to 3.2.2), or blank
for "not guaranteed".  Then genmessages can be used to produce
suitable baselines we can use for comparisons with future catalogs.

But again, that's not really a design decision (aside from providing
the tagging syntax).

> The "flexibility" we have now in our warning logic is probably a
> mistake; it's part of why we have inconsistently worded messages
> throughout the compiler.  We should probably be trying to merge
> these similar messages into a single message so they can be turned
> on/off easily.

The design I have in mind allows for messages to be grouped; perhaps
the *groupings* are what need to remain stable?  The "single message"
you refer to would instead be a single control point which controls a
set of messages with similar meaning but slightly different wording?

Again, though, this is a policy issue, not a design issue.