Don't abort compilation after giving a lint error by jyn514 · Pull Request #87337 · rust-lang/rust (original) (raw)

Making the compiler not stop after an error would render different lint levels useless. The only difference then would be that they have a different color in the terminal.

What I imagined when filing #82761 was not that the compiler would not abort on error-level lints, but that it would not abort early. That preserves an important difference between error and warning lint levels: a lint being error-level would still cause the compiler to not emit compilation artifacts and exit with nonzero status (resulting in e.g. a CI run reporting failure instead of success), unlike a warning. I don't think anyone is advocating that compilation should actually succeed if there are error level lints* (in situations where that is desirable, as you note, --cap-lints exists); I think it would be a bug in this PR if it causes that to happen.

(*EDIT: Actually @jyn514 did talk about having cargo builds keep going into dependent crates in the case of lint errors, which I guess requires this to some extent, but I think we would want to preserve a sense that the build overall has failed, e.g. cargo would not exit with a zero status.)

If you already have erroneous code at the source-level (AST), then you should fix those first, before the linter tries to check type information or borrowing stuff.

This is reasonable for hard errors (and sometimes completely necessary - for instance the compiler can't typecheck code that it can't parse into an AST), but I'm not convinced this is the case for lints, especially those that come from external tools like clippy - it seems less likely that a problem that would trigger a clippy lint, but otherwise would still allow the code to be compiled, would cause that kind of cascade of errors where the later diagnostics don't add value.