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

[Ruben Van Boxem]

Op 16 aug. 2011 19:20 schreef "David Blaikie" <dblaikie at gmail.com> het
volgende:
>
> >> 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.

What about errors that produce more than one note (like c++ function
overload suggestions)?
>
> - David
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110816/1d7b228b/attachment.html>