This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Improving C++ error output?
- From: Joe Buck <jbuck at synopsys dot com>
- To: jsalz-gccbbf at mail dot jsalz dot net (Jon Salz)
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 20 Dec 2002 14:20:15 -0800 (PST)
- Subject: Re: Improving C++ error output?
> 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.
> 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.