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

[David Blaikie]

>> IMO, no. We should get it right. 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.
>
> So lets say our limit is 1 and there is only one error in our translation
> unit. In this case we wouldn't get the fatal error?

No, I think what he's saying is rather than emitting the fatal error
when you see the <limit> error message (when you see the first error
when limit is 1, in your example) - wait until you see the <limit>+1
error and emit the fatal error then.

That seems more correct anyway - if you asked for an error limit of 3
and you only produced 3 errors you shouldn't get the fatal message
because there was no problem:

Given this:

$ clang++ foo.cpp -ferror-limit=2
foo.cpp:5:15: error: no member named 'stuff' in
      '__gnu_cxx::__normal_iterator<char *, std::basic_string<char> >'
  foo.begin().stuff();
  ~~~~~~~~~~~ ^
1 error generated.

This seems unnecessary:

$ clang++ foo.cpp -ferror-limit=1
foo.cpp:5:15: error: no member named 'stuff' in
      '__gnu_cxx::__normal_iterator<char *, std::basic_string<char> >'
  foo.begin().stuff();
  ~~~~~~~~~~~ ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
2 errors generated.


Too many errors were not emitted - one error was emitted so there's no
problem. If you implement -ferror-limit by waiting for the N+1th error
& outputting the fatal error instead of the N+1th error then you'll
fix this note problem & the above weirdness won't occur. I believe
that's what Doug was suggesting.

- David