Patches to the FAQ and the fatal error messages for guiding bug-reports better

Mark Mitchell mark@markmitchell.com
Tue Sep 15 01:22:00 GMT 1998


Jeffrey A Law wrote:
> 
>   In message < 199809101911.MAA22991@smtp.earthlink.net >you write:
>   > By the way, we actually need more infrastructure to support this
>   > correctly.  For example, the C++ front-end sometimes wants to print
>   > long lists of things (for example, all the functions named `f' which
>   > you might have meant when you wrote `f(3)' and it couldn't make sense
>   > of it.)  Because these lists are of variable length, the only way to
>   > print all of them with a single call to `warning' would be to
>   > format the error message on the fly with something like:
>   >
>   >   for (i = 0; i < num_things; ++i)
>   >     strcat (format, "\n  %s");
> Ugh.  But does this mean we should introduce multiple calls to
> warning in the cases where we can clearly do what we want with
> an embedded newline?

In my opinion, yes.  This goes to my earlier point: error messages are
not just strings.  One can easily imagine that if the compiler used
the proposed continuation interface throughout, that one could
change the actual error message generation routines to generate HTML,
do word-wrapping, or hook into an IDE.  (I've used such an interface
to do all these things, in the past.)  It's not nearly as pleasant
to do these kind of things if the caller is trying to do formatting
themselves.  The whole point of the error()/warning() interface, IMO, 
is to protect the GCC developers from having to worry about how
to format error messages; they should just give the messages to the
interface, and it should insert newlines, leading spaces for
continuation lines, etc., as it sees fit.  For instance, these functions
now insert file and line information, and the word "warning" if
necessary.  I think newlines and leading spaces are just the logical
extension of this.

> I've got no problem starting this conversion, but I don't want to see
> us go and convert all the errors/warnings -- that would effectively
> lead to the same gcc2 merge problem.

Understood.   

> We could declare the new start/continuation scheme as the way to
> deal with all new warnings, then go back and deal with the old ones
> once we've made some long term decisions re: gcc2.  Not optimal, maybe
> not worth the effort.

I think this is the right thing to do.  It will give us a chance to 
nail the interface down by experimenting with new messages; we can then
convert the rest of the compiler when appropriate.

-- Mark



More information about the Gcc-patches mailing list