On 2005-02-23, at 18:40, Gabriel Dos Reis wrote:
Factually the support for error handling by integration in to externalndards for error messages, etc.)
That certainly would require changing many things, e.g. Emacs support and like. That is a reason why I approach this issue conservatively.
tools from gcc is generally very bleak inside those tools. I would assume
that the current error reporting format used by GCC is one of the reasons for
this. Every time I see gcc reporting tens of k errors after discovering a
serious parser error for no good reason running out of every xterm scroll back
buffer I really ask myself why nobody every didn't limit this to some sane bail out value.
The presumption that letting the compiler churn may help non-interactive builds
is wrong at this era: The compile time of a single file isn't an issue at all and
continuing to compile a broken program is just a waste of energy resources and
an annoyance for the command line user.
