This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: named warnings & individual warning control

DJ Delorie wrote:

In fact, I've done this exact same thing before on the exact same issue in another compiler, and had precisely this problem: lots of unhappy customers when the ids changed, even when we explicitly told them that they would.

It sounds like you've defined the problem in such a way that it can't
possibly be solved. I'm trying to find a compromise that gives us as
much of what the user needs with the least of the maintenance
problems, or at least lets the user hack it with a minimal effort.

No, the problem can be solved: you just have to be very disciplined about how you add and remove messages.

This is probably good -- although it was also true of my patch, and
some people were very much opposed to not being able to just tweak
the source code.

The message catalog is still part of the source code, no different
than (say) tree.def or

You are preaching to the choir here; that was exactly the approach I took, It met with opposition because the messages were separate from the places that decided to generate them. That is the objection you have to overcome -- perhaps by finding that nobody objects anymore. I do think you should specifically ask Jason, as he felt strongly IIRC.

A compromise is to pass an ID and the text, allowing for specific
message IDs but initially passing group IDs. The catalog would
initially contain only the grouping logic, tags, and possibly
alternate texts, although migrating the texts out to the catalog would
become more automatable with time as the IDs become more specific. It
would also be easier to generate a report of which IDs are used in
more than one place (i.e. which are groups and which are specific

Yes, I think something like this is probably pretty non-controversial. To me, the controversial parts are (1) moving the messages away from their generators, and (2) providing fine-grained control of warnings until we have a clear consensus on what we want to do about release-to-release maintenance.

Mark Mitchell
CodeSourcery, LLC
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]