-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Don't run allowed lints #75605
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 #75605
Conversation
This is still running some things, not sure why. ``` warning: hidden lifetime parameters in types are deprecated --> ui/lint/reasons.rs:21:29 | 21 | fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { | ^^^^^^^^^^^^^^- help: indicate the anonymous lifetime: `<'_>` | = note: explicit anonymous lifetimes aid reasoning about ownership note: the lint level is defined here --> ui/lint/reasons.rs:5:9 | 5 | #![warn(elided_lifetimes_in_paths, | ^^^^^^^^^^^^^^^^^^^^^^^^^ ``` However most of the lints have gone away.
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
I worry that such a blanket run-prevention may cause problems, e.g., future compatibility lints should still be shown in dependencies sometimes. Are we confident none of the lints are actually emitting hard errors? I would feel uncomfortable doing this without an audit (and ideally some machinery to prevent it entirely). |
I don't know how to measure the performance improvements for this, AFAIK rustc-perf only runs on the last crate, not on any dependencies. Maybe we could change one of the benchmarks to use |
Hmm ... I kind of assumed that lints wouldn't ever emit hard errors, but I'm not sure whether that's actually the case. How would I find out? |
Well, they probably shouldn't be, but I don't know of a good way to do that. I guess we can try to check the number of errors emitted before/after the pass and ICE if that's different, but that's pretty not great, and is a runtime check so we won't catch interesting cases probably. We could also try and manually look through all the lint impls but that seems likely to miss things (especially since they're constantly changing). |
I can implement that for now and see if anything pops up. |
☔ The latest upstream changes (presumably #74862) made this pull request unmergeable. Please resolve the merge conflicts. |
Some places that should have an assert added:
probably others, so it gets early lints as well |
Triage: There's merge conflicts now. |
The merge conflicts are not where the work is 😆 this needs a lot more work implementing #75605 (comment) before it can even be reviewed. |
So I don't lose it: the zulip conversation about this was https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/lint.20avoidance |
marking this as draft |
I'm probably not going to get around to this. |
Partial implementation of #74704.
Not sure exactly why some lints are still run - I think they're being added later with
register_lint_pass
? I don't understand the machinery inrustc_lint
very well. However this still cuts off a solid percent of the runtime: #74718 (comment) and further improvements can be done in follow-up PRs.