This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

  In message <>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?

Note that I wouldn't have even raised the objection if it wasn't for
notes I'd read from various C++ folks about the desire to only call
warning once for each problem :-)

  > Since my proposal has been rejected,
Let's call it tabled until the long term issues with gcc2 merges are
sorted out.  As for using warning/error #s, I think it's the wrong
thing to do and it's discouraged by the GNU standards, but I'm willing
to consider them too once the long term gcc2 merges issues are sorted

  > 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.
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.

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.

If we don't think avoiding multiple calls to warning for new warnings
is worth the headache at this time, I'll withdraw my objection to
that aspect of the patches.  I was only trying to take a step forward
on an issue raised in g++ land :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]