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

[Mark Mitchell <mark at markmitchell dot com>]

>>>>> "Per" == Per Bothner <bothner@cygnus.com> writes:

    >> Mark's facility is really for people who get hundreds of
    >> identical warnings, and want to shut up all of them.

    Per> Tell me again why this can't be done using sed, or an IDE
    Per> (Cygnus provides Foundry), or an Emacs compile mode tweak?

I don't understand this comment.  Sometimes, one must use source for
which one does not have write access.  Foundry is not free software,
IIRC.  Not everyone uses emacs.

    Per> In any case, GNU has a standard framework (gettext?) for
    Per> internationalizing messages.  Gcc is being converted to use
    Per> that.  I think any error message catalog facility that does
    Per> not build on the existing GNU standards is just not in the
    Per> running.  (You would have to convince a lot of people that
    Per> the existing framework is badly flawed, and you can provide
    Per> something better where the gains outweigh the pains.)

The internationalization issue is completely orthogonal.  I brought
this up because I believe my patch would make it *easier* to use
gettext, not harder.  In particular, with my patch, almost all
internationalization could be taken care of with one call to `gettext'
in one place, rather than be littered throughout the source code.
Similarly, adding new error message would not require remembering to
use `_()' (or `gettext()').  There is *nothing* incompatible about the
two schemes whatsoever.  The reason for the emphatic nature of this
paragraph is that I don't want this confusion to affect the overall
discussion.

Jeff has raised a vaild concern: namely that merging in the GCC
conversion to gettext would be more difficult in the presence of my
patch.  I'm not actually even sure that would be so (because of the
above), but it's almost certainly not worth discussing; it's just as
easy to apply my changes after the merge as before (assuming we want
to do that.)

    Per> Instead, what we might consider is gettext extension so a
    Per> user can easily add a hook to suppress a specific message.
    Per> This would be a variant of the hooks to allow the user to
    Per> control message catalog, but using a special magic
    Per> "translation" of (for example) "<<suppress message>>".

That's an idea.  But, as I've tried to say before, and as Craig
pointed out, there is more semantic content in error messages that
simply their words.  For example, g++ sometimes issues multi-line
messages where the first line uses one message, and subsequent lines
use another.  Conceptually, however, all these messages are part of
one single idea; users should be able to turn the whole bunch off with
one stroke (again, assuming you think that users being able to turn
off warnings is a good idea).

Craig pointed out that the warning messages could be organized
hierarchially, so that you could say "no messages about <x>".
Essentially, this is what we have done (by special-cases) with all the
-W flags; -Wno-blah says don't warn me about blah.  But, the mechanism
for doing this is just a bunch of `if' statements in the code, adding
new flags requires modifying a bunch of files and adding new `if's,
and users have no control whatsoever of how the organization takes
place.  

In summary, it's my opinion that the functionality I proposed is not
available as a simple gettext extension.

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