Warnings in the C++ Front-End and GCC in General

[Mark Mitchell]

Craig --

  Thanks very much for your comments.  I think all of your (gentle)
criticisms are valid.  I also think, however, that there are some
mitigating factors.

  I make a few notes below:

  o There are a lot of improvements that can be made to the scheme I
    suggested.  Fortunately, I think most of them are generalizations.
    For example, you make the excellent suggestion of a warning
    hierarchy.  In the C++ front-end (and if my proposal flies, in the
    GCC core), we now have enable_warning and is_warning_enabled; to
    support such a hierarchy all that is needed to modify these
    functions appropriately.  Now that the errors have codes, they can
    be organized in various ways.

  o You wrote:

    > Specifically, a means to enable/disable, and perhaps even push/pop,
    > a particular kind of warning would be useful if it could work
    > within macro expansion.

    > being able to push/pop the status of a warning
    > is fairly important

    Yes; pushing/popping is essential to make all this make sense.
    I didn't do this yet, because there is no way to enable/disable
    warnings in the source, yet, but this can and will be done when
    we agree on the mechanism for enabling warnings in source code.

    The point that #pragma cannot be generated from a macro is a good
    one.  One possibility would be an __extension__ like facility.
    In fact, that now makes some sense to me.  Just as you can
    say:

      __extension__ /* Some declaration that -pedantic would complain 
                       about.  */

    you could say:

      __enable_warn__(xxx) ....

  o You comment that people will think that:
  
    > adding new warnings is always okay now that people can
    > individually disable them in a chunk of code

    As you point out, people suggest all kinds of odd "enhancements"
    to GCC all the time.  It's the responsibility of the maintainers,
    directly, and the rest of us, indirectly, to decide the merits
    of these proposals.  I, for one, will oppose and C++ warning that
    I don't think is going to be useful a lot more often than not.
    I used to work on an error-checking C/C++ system (at CenterLine,
    these were the Saber-C/C++ -> CodeCenter/ObjectCenter -> C++Expert) 
    series, and believe me, we learned the value of avoiding false
    positives!  We also learned how important it ws for users to be
    able to suppress warnings and errors effectively.

  o You also point out that:

    > No new, readable, linguistic information is added to the dialect
    > The facility is inherently non-portable

    Both true.  Unfortunately, I don't really see a way around these
    issues.  We don't issue the same warnings as other compilers,
    so portability doesn't seem likely.  And, warnings, as opposed to
    errors, usually indicate that some construct, while legal, is
    unlikely to be the one you wanted.  So, I'm not sure what 
    linguistic information would be useful.  Instead of numbers
    we could use mnemonic codes, perhaps the error codes themselves?
    Would you rather use:

      __disable_warn__(blah_blah_you_really_maybe_meant_blah)

    as opposed to:

      __disable_warn__(85)

    I rejected these as being too hard to type, and because it would
    mean that non-English speakers would have to use English codes 
    for error messages.

  o You also discuss the issue of warning codes changing from 
    release to release.  That's a valid concern.  We can avoid it
    to some extent.  (For example, in cp-error.def, there are
    instructions that error codes *not* be removed from the list since
    that will change the numbers.)  The disable-by-name rather than
    disable-by-number scheme might also help in this regard.

    I think that over time the "warning contour" *is* likely to
    change, at least slightly.  People who use the warning diable
    facilities heavily in their code, especially to cover up real
    problems, will suffer as a result.  Appropriate cautionary notes
    in the manual are probably in order.

    Fortunately, incompatibilities here will only lead to warnings, so 
    it's not like we'll really break anybody's code.  (I'm not
    underestimating the seriousness of having to change your code to
    adopt to the new "warning contour", only pointing out that the
    problem is not of the most severe variety.)

  o You suggest that:
 
    > some of this is just working around significant
    > deficiencies in C, C++, Fortran, et al as programming languages
    > (which we could try and solve
    
    There are certainly deficiencies in all those languages.  They
    are, however, the languages mandated by their appropriate
    standards, and there's not much we can do about them.  I think GCC
    has too many odd extensions as it is.  But, perhaps that's not
    what you meant?

  o Although you point out that figuring out where a particular error
    is coming from gets a little harder, I'll point out that a simple
    emacs macro (or shell script) should fix that problem.  And, I
    think there are numerous potential GCC maintenance improvements:

    o A single mechanism for generating diagnostics will allow 
      more code sharing/reuse.

    o Internationalization should be easier if messages are collected
      in a single file, not in the bowels of the source.

    o It will be easier for people who find mis-worded or unclear 
      messages to submit patches to fix them, and easier for us
      to accept them.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com