Improving C++ error output?

[Jon Salz]

Randy, this is an excellent illustration why I think it might be more
useful to make error output machine-readable, rather than improve its
human-readability.

Another reason is that what's more readable to one human is going to be
less readable to another; making it possible to decouple error reporting
from the compiler would make it orders of magnitude to customize this.

-fmessage-length=0 is a good start; it also helps to look at the
indenting of error messages, e.g.:

cc1: warning: changing search order for system directory "/usr/include"
cc1: warning:   as it has already been specified as a non-system
directory

-fmessage-length=0 doesn't turn this into one line, but "as" is preceded
by two spaces, which tells you it's part of the previous line.

- Jon

On Fri, 2002-12-20 at 18:16, Randy.Dunlap wrote:
>
> | > To most developers I know, the number one annoying thing about C++/STL
> | > programming is deciphering inane error messages.  (For example, forget
> | > to declare an iostream operator << for your data type, and you're
> | > treated to a 75-line error message detailing all the candidate operator
> | > <<s; informative, but way *too* informative.)
> |
> | -fmessage-length=0 can help a bit, especially if you want to postprocess
> | (automatically or with an editor).  But yes, there's no point in reporting
> | more than a relatively small number of candidates (default, say, to three,
> | report the first three, then a count of how many more aren't printed).
> | A user option could change the threshold.
> 
> I'm interested in this thread because OSDL is building each new Linux
> kernel release and checking for (many) warnings and errors.
> (There is some early sample output at:
>   http://www.osdl.org/archive/cherry/stability/2.5.52.results/
> )
> 
> We could stand to see more consistency in warning and error messages,
> unless things like (above:) -fmessage-length=0 will help out.
> I'll try that now.
> Multi-line messages can also be a problem for post-processing/automation.
> 
> Any hints or clues on how to do this consistently and successfully?
> 
> | > Has there been any work towards making g++ error output easily
> | > machine-readable?  E.g., a command-line flag --error-format=xml causing
> | > errors to be output in XML.  If I did some work toward this end, would
> | > it have a shot at being accepted into the g++ tree?
> |
> | I'm not sure that this is the right approach.  If you can do something
> | intelligent in a post processor, it could probably be done better inside
> | the compiler where more information is available.
> 
> Thanks,