This is the mail archive of the gcc@gcc.gnu.org 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


> 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.

> 1) I don't have much time, so I'll implement something first.

Ok, this applies to me ;-)

> 2) Now I have an implementation, so I'm very resistant to changing
> the implementation.

I'd like to think this does not apply to me.  Code to me is language,
if we don't code we aren't communicating as well as possible.  Writing
code is not just for the final implementation, but as a way of trying
out ideas.  One thing I learned at a previous job is that we've
(sadly) lost the abililty to throw away prototypes and try again.

> 3) Also, since I have an implementation, I really want it to be
> checked in; I don't want to have maintain this code myself.

I have lots of patches that never got checked in.  Personally, I don't
care about the implementation as long as the functionality exists
somehow, because we have customers complaining - loudly - for it, and
even if we can reduce the maintenance burden of their local hacks it
would be worth the change.

> I think every major GCC contributor, myself included, is guilty of 
> having done this at least once.

Some would argue that, that's how progress is made ;-)

> I do think we learn a lot from implementation, and nobody's going to
> stop you from implementing stuff, but in this case the
> implementation is going to be relatively mechanical (my patch took a
> couple of days, for example).  If there's no buy-in from
> maintainers, then we haven't gained much over the current situation.

We've been arguing this issue for at least six years.  How do we make
progress, if not by doing something?  Pure discussions have a poor
track record, not because the issue keeps getting shot down, but
because the issue keeps getting *dropped*.

> >By definition, ALL messages would have a user-visible mnemonic,
> >however ugly. 
> >
> This is the kind of thing I think is important to decide.

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.

> 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.

> The current system, at least, does not make any false promises.

Nor does it do what the users want.

> Now, from a technical point of view, if you put all the messages in
> a catalog, and tagged them with their existing warning categories --
> but didn't change the user interface at all -- that would just be a
> technical patch, and we could consider it on its technical merits --
> is it easier/harder to maintain, etc.

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.

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

* 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.

* 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.

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

* 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).

* 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)).

* It lets GCC developers have an overview of what we must keep
  consistent across releases (and allows for automated auditing of
  such).  A centralized catalog allows us to, for example, tag a
  warning or grouping as "locked" in a release branch, and a cron job
  can enforce that locking.  For example, when 3.5.0 branches, add
  "lock=grow" to -Wformat so messages can be added but not removed or
  changed.

* 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.


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