Improving C++ error output?

[Randy.Dunlap]

On Fri, 20 Dec 2002, Joe Buck 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,
-- 
~Randy