-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lint errors make rustc abort early #82761
Comments
Come to think of it, if a lint from any source, including internally, could have its level be set to |
Note that this would need cargo support if you have a path dependency. rustc would print all lints for the first crate, error out, and then cargo would see the error and stop before compiling the next crate in the workspace. For cargo to avoid that, rustc needs to tell it somehow that these are 'lint-only errors'. |
@sxlijin @SNCPlay42 feel free to open a new issue for showing all lint errors across a workspace :) it should probably be under rust-lang/cargo. |
Hurrah! Many thanks :) |
Don't abort compilation after giving a lint error The only reason to use `abort_if_errors` is when the program is so broken that either: 1. later passes get confused and ICE 2. any diagnostics from later passes would be noise This is never the case for lints, because the compiler has to be able to deal with `allow`-ed lints. So it can continue to lint and compile even if there are lint errors. Closes rust-lang/rust#82761. This is a WIP because I have a feeling it will exit with 0 even if there were lint errors; I don't have a computer that can build rustc locally at the moment.
In general, the compiler tries to keep going after errors to emit as many helpful diagnostics as possible. This isn't always possible because later stages of compilation might need certain conditions to be upheld, so sometimes the compiler aborts early.
It should never be necessary to abort early due to a lint
from an external tool (e.g. clippy)because the compiler's hard errors should be sufficient to enforce conditions needed by later stages.At present, however, error-level lints
emitted by external toolscan cause compilation to abort early. It seems unfortunate that, after fixing all the problems reported by one run of clippy, you could run clippy again (perhaps by committing your "fixed" code and updating a PR, causing CI to run) and discover there are more problems (when CI fails).As an example, this code:
Emits two lints with clippy:
If
#![deny(clippy::all)]
is added, only the first lint is emitted, and the compiler aborts after it:@rustbot label A-lint
The text was updated successfully, but these errors were encountered: