Re: named warnings & individual warning control

[Mark Mitchell <mark at codesourcery dot com>]

DJ Delorie wrote:

> > I did provide an implementation way back when.  I'm not saying it
> > was a great implementation, but it did work; it was in the tree for
> > less than 24 hours before Jason yanked it back out.  At that time,
> > the policy decision was "we don't want this feature".
> >    
>
> It's come up so many times in the past that I think whether *we* want
> this feature or not is now irrelevent; enough gcc users want it to
> justify it, else we're doing a disservice to the gcc user community.
>  
I agree; this would be a useful feature, if we can figure out how to do 
it, and if we have the resources to maintain it.  The reason I 
implemented it once before was because people wanted it.  However, there 
is a real cost here: adding new messages becomes harder, and has more 
interface implications for users from release to release. 

That's why I think that you need to get consensus on this issue before 
you get too committed here.

> Granted, if we don't want individual control over messages, this whole
> project is a lot less useful.  However, we have customers who really
> need this functionality, and have resorted to manually editing gcc's
> sources to do what they need.  I think we all agree that such a
> "solution" is possibly the worst available solution.
>  
Actually, no.  Even worse is to have code that is hard to maintain in 
the compiler, or to make promises to our users that we can't keep.

> > The problem, in my mind, is that as soon as you provide the mnemonic, 
> > people will want and expect it to be stable, no matter what else you 
> > tell them.
> >    
>
> My original post indicated that we make it clear that such mnemonics
> WILL (not may) change.  We can programmatically renumber them for each
> release to keep people honest (IIRC Apple did something similar with
> their BIOS to keep app developers from cheating) but I suspect that's
> overkill.
>  
I don't think this is a problem you can solve with documentation.

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.

> Ok, let me propose this: Messages with numeric suffixes will be
> unavailable to the user.  This is a trivial restriction we can add to
> any design, which allows us to obtain the benefits (TBD or as listed
> below) of a new design, plan for future policy changes (and perhaps
> implement them trivially), and - for those customers who absolutely
> must have such control - the ability to maintain a local patch easier.
>
> (Or, take a clue from sendmail and add a
> "-Wlet-me-control-warnings-that-will-change-in-the-next-release"
> option ;-)
>
> Given that, I think a new design can still provide benefits:
>
> * The user can still control warning groups from within the code
>  (i.e. #pragma GCC message ignore format, #pragma GCC message error
>  writable-strings, etc), even if such groupings are no more flexible
>  than the set of -W options we currently offer.
>  
Yes, agreed; that, I think is non-controversial functionality.  Note 
that you could do this without a central warning catalog.

> * Grouping of messages into command line options is centralized
>  (leading to easier auditing, machine-generated documentation,
>  reverse indexes, {user,target,language}-definable groups, etc).
>  
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.

> * Logic for deciding if a standard cares about a message, for example,
>  can be moved out of the code (reducing code complexity there).  This
>  may or may not be easier on the developer, but it allows for some
>  standards auditing reports to be automatically generated.
>  
This is desirable -- but may not be easy; sometimes the same message 
might result from undefined behavior in some cases but just a warning in 
others.  I'm not sure.

> * We can provide both a terse and a verbose text for each message, and
>  let the user select which they desire.  Or perhaps link to online
>  documentation relevent to each message printed.  Lots of flexibility
>  here.
>  
Yes.

> * GCC could be told to print, for each message printed, the option(s)
>  which control the group(s) that message is(are) in.
>  
Yes.

> * Grepping for mnemonics in the code is slightly easier than grepping
>  for strings, especially when it's not obvious which bits of the
>  strings come from the format and which come from the arguments
>  (DAMHIKT).
>  
Yes.

> * We can provide a more flexible alternative to -Werror (it was
>  proposed to use -E* like -W*, for example, -Eformat is like -Wformat
>  but it's an error instead of a warning (-E alone is its old meaning
>  still)).
>  
Yes.

> * Deferring the categorization of a message as an error, warning, or
>  whatnot - and thus treating them the same whenever possible - makes
>  us (gcc developers) think about what MUST be an error and what only
>  DEFAULTS to being an error.
>  
Yes -- although given our current codebase it's very dangerous to relax 
errors to warnings.  It's also a problem for backwards compatibility; 
sometimes what you could tolerate in one release is not the same as what 
you can tolerate in the next.

In general, I agree with your benefits list -- but I think you need to 
get buy-in on the idea that centralizing the message database is a good 
thing.  For example, I think you need to get Jason to agree that he no 
longer objects to this -- or decide explicitly to ignore his objections. :-)

Note that you could get some of the same benefits by just adding the 
#pragmas for the current warning groups, and by having calls to 
"warning" take an optional group flag word, which you would then insert 
at the call sites.  When warnings for that group were disabled, the 
calls would return immediately.   I don't think there are any major user 
interface impliciations of that; it's a clear win.  And, it doesn't have 
the same maintenance or methodology implications for the rest of the 
compiler.

I understand why that's not as atttractive from some other perspectives, 
but I think it should be on the table as well.

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com