Skip to content
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

Don't run allowed lints #74704

Closed
jyn514 opened this issue Jul 24, 2020 · 4 comments
Closed

Don't run allowed lints #74704

jyn514 opened this issue Jul 24, 2020 · 4 comments
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-enhancement Category: An issue proposing an enhancement or a PR with one. I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jyn514
Copy link
Member

jyn514 commented Jul 24, 2020

First noticed in https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Output.20of.20.60collector.20eprintln.60/near/204875468. If a lint is allowed, there is no need to run the lint pass. This could have large performance improvements for any crate where all lints are allowed (e.g. any dependency compiled by cargo, which uses --cap-lints allow).

As a first pass this could check for --cap-lints allow and run no lints if so. In the future it could skip individual lints. Rustc would have to be careful not to skip lints that are #![allow]ed at the crate level but re-enabled for individual items.

The implementation would look similar to what I did in #73566 - override the query provider for lint_mod so that it doesn't run lints at all.

@jyn514 jyn514 added I-slow Issue: Problems and improvements with respect to performance of generated code. C-enhancement Category: An issue proposing an enhancement or a PR with one. A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. labels Jul 24, 2020
@JohnTitor JohnTitor added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jul 24, 2020
@jonas-schievink jonas-schievink added I-compiletime Issue: Problems and improvements with respect to compile times. and removed I-slow Issue: Problems and improvements with respect to performance of generated code. labels Jul 24, 2020
@jyn514
Copy link
Member Author

jyn514 commented Sep 16, 2020

@flip1995 mentioned that this is a hard problem in general:

one LintPass can have multiple lints (which makes sense for performance and DRY) and only can be skipped, iff all lints in the lint pass are allowed. Clippy has a "workaround" for this:

https://github.com/rust-lang/rust-clippy/blob/06f190287848ceeee36be738cbbd8e008f3e7615/clippy_lints/src/utils/mod.rs#L1402
https://github.com/rust-lang/rust-clippy/blob/c493090a8a601baea39a592fdbe199bd64d6db22/clippy_lints/src/wildcard_dependencies.rs#L33

Also, this only works for LateLintPass.

@camsteffen
Copy link
Contributor

We could put allow-by-default lints into a separate pass. Then disable the whole pass if all those lints are never enabled in the crate?

@blyxyas
Copy link
Member

blyxyas commented Nov 13, 2023

Maybe CC

@bjorn3
Copy link
Member

bjorn3 commented Dec 6, 2024

Fixed by #125116

@bjorn3 bjorn3 closed this as completed Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-enhancement Category: An issue proposing an enhancement or a PR with one. I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants