Don't abort compilation after giving a lint error by jyn514 · Pull Request #8733...

flip1995 commented on Jul 21 •

Copying my comment about this from Zulip:

If you don't want the compiler to abort on a deny-by-default lint, then you can just use --cap-lints=warn. Preserving the lint levels and keep going even if there is an error makes lint levels completely nonsensical.

IMO not aborting after an error, even with lints, is a bad idea. Here's why:

The compiler works in stages / IRs and so do lints. So there is the AST, where source-level checks are done, the (T)HIR where type checking and similar things happen and the MIR, where borrow checking and the like happen. 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.

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.

So I'm against this change, especially since there already is the --cap-lints flag where you can tell the compiler to ignore all lint levels above a specific level.

This will definitely fail the Clippy test suite, since our UI tests make the assumption that an error in an EarlyPass lint will prevent LatePassLints from running. And so does rustc:

test result: FAILED. 11623 passed; 424 failed;