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

Mark Mitchell mark@markmitchell.com
Thu Sep 10 12:09:00 GMT 1998


>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

    Jeffrey>   In message < 199809100915.LAA05487@scar.axis.se >you
    Jeffrey> write:
    >> No and yes.  The construct I used is already there, and I don't
    >> see any error/fatal/ack (or warning for that matter) with
    >> embedded newlines.  See for example c-decl.c:1686 (circa), and
    >> elsewhere.
    Jeffrey> See the other thread about fine grained control of
    Jeffrey> warnings.

    Jeffrey> The fact that we call warning() multiple times for a
    Jeffrey> single warning is a long standing bug in several places
    Jeffrey> in the compiler.  We should fix them, but in the mean
    Jeffrey> time we should not add more instances of the bug.

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");

That's not even good enough because you then can't pass all the
fill-in strings to warning, so you'd have to manually fill them all in
yourself:

  for (i = 0; i < num_things; ++i)
    /* Assume ANSI sprintf just for discussion... */
    format += sprintf (format, "\n  %s", thing[i]->name);

What a pain!

You should be able to do:

  warning_start ("This is the beginning of the warning ...");
  for (i = 0; i < num_things; ++i)
    warning_continuation ("  %s", thing[i]->name);

and have warning_start/warning_continuation handle do whatever
prefixing of lines is appropriate.  Of course, if we had a
centralized place to keep track of the messages, that table could
indicate whether or not they were continuation messages, and then we
could write:

  warning (ec_beginning_of_message);
  for (i = 0; i < num_things; ++i)
    warning (ec_a_thing, thing[i]->name);

Aw, shucks: that's almost we've got now!  So, substituing enumerals
for the strings, and then editing that table to mark continuation
messages would fix the whole multi-line message problem in one fell
swoop.  This is precisely what I mean when I say diagnostics have more
structure than just simple strings!  Once you collect the diagnostics
into some kind of table, you can manipulate them in many interesting
ways.  (For example, the EDG front-end lets you set the severity of
any message, so that warnings can become errors, or be silenced
completely.  You can't turn off errors, of course.)

Since my proposal has been rejected, I think we should do the
warning_start/warning_continuation bit.  I *don't* think adding
new-lines in the middle of message strings is the appropriate thing.
Besides the problem mentioned here (it's not fully general), it's also
constraining: it prevents us enhancing the error-message printing
routines to do automatic word-wrapping and line-breaking, say.

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



More information about the Gcc-patches mailing list