[cfe-dev] -ferror-limit omits part of last error message

[David Blaikie]

> One way to do so would be to emit the fatal
> error rather than the first error that would exceed the threshold, rather
> than following the last error that is permitted within the threshold. That's
> probably easier in general.

Like this? (patch attached, no test cases yet) - I don't know if I
should be doing something better than SetDelayedDiagnostic now that we
don't really need to delay it at all.

Examples:

foo.cpp contains one overload error
foo2.cpp contains two overload errors

Old behavior:

$ clang++ foo.cpp -ferror-limit=1
foo.cpp:4:3: error: no matching function for call to 'foo'
  foo();
  ^~~
fatal error: too many errors emitted, stopping now [-ferror-limit=]
2 errors generated.
$ clang++ foo2.cpp -ferror-limit=1
foo2.cpp:4:3: error: no matching function for call to 'foo'
  foo();
  ^~~
fatal error: too many errors emitted, stopping now [-ferror-limit=]
2 errors generated.

New behavior:

$ clang++ foo.cpp -ferror-limit=1
foo.cpp:4:3: error: no matching function for call to 'foo'
  foo();
  ^~~
foo.cpp:1:6: note: candidate function not viable: requires 1 argument,
but 0 were provided
void foo(int);
     ^
1 error generated.
$ clang++ foo2.cpp -ferror-limit=1
foo2.cpp:4:3: error: no matching function for call to 'foo'
  foo();
  ^~~
foo2.cpp:1:6: note: candidate function not viable: requires 1
argument, but 0 were provided
void foo(int);
     ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
2 errors generated.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error-limit.patch
Type: application/octet-stream
Size: 876 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110816/f4252aed/attachment.obj>