[cfe-dev] -ferror-limit=1 by default?

[Richard Smith via cfe-dev]

We work pretty hard to make errors after the first as robust as possible;
if the user experience is that our recovery from errors in some particular
case is bad, we should try to fix that before resorting to a default of
-Wfatal-errors / -ferror-limit=1.

We also have some unusual cases where the first error reported is actually
a consequence of a later error (or warning) that we've not yet diagnosed.
This can happen due to our taking the unintended path through a parse
ambiguity, or (occasionally) due to our attempt to work out how
to diagnose an error (particularly in typo correction) encountering further
errors. Stopping at the first error can in rare cases completely hide the
error message that explains what's wrong.

I think it's better to view this as a class of individually-fixable
problems rather than a systemic problem, identify the particular cases
where our error recovery is bad, and improve those cases.

On Thu, Nov 7, 2019 at 3:10 PM Michael Kruse <llvm at meinersbur.de> wrote:

> Without having an opinion on what should be the default, I find
> -Wfatal-errors more idiomatic. Errors after the first are not robust
> and I have no use case for "I need exactly 2 errors". Rather, if the
> following errors might be useful, I'd remove the -Wfatal-errors and
> less/scroll though the entire list.
>
> Michael
>
> Am Do., 7. Nov. 2019 um 16:05 Uhr schrieb Eric Christopher <
> echristo at gmail.com>:
> >
> > There is! I think one of the things I like is that -ferror-limit also
> > says "if you'd like more warnings then you can use a different option"
> > rather than something like -Wfatal-errors.
> >
> > Also thinking about usability defaults for the greater good rather
> > than my use case. I set my own command line options like I like :)
> >
> > -eric
> >
> > On Thu, Nov 7, 2019 at 1:56 PM Michael Kruse <llvm at meinersbur.de> wrote:
> > >
> > > Note that there also is a -Wfatal-errors option.
> > >
> > > Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191112/b473ffd2/attachment.html>