named warnings & individual warning control

[Mark Mitchell]

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 target.md.
>  
>
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
>messages).
>  
>
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
mark@codesourcery.com