-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Skip if-let-rescope
lint unless requested by migration
#132666
Skip if-let-rescope
lint unless requested by migration
#132666
Conversation
rustbot has assigned @petrochenkov. Use |
if-let-rescope
lint unless requested by migration
r? @Kobzol |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…-lint, r=<try> Skip `if-let-rescope` lint unless requested by migration Tracked by rust-lang#124085 Related to rust-lang#131984 (comment) Given that `if-let-rescope` is a lint to be enabled globally by an edition migration, there is no point in extracting the precise lint level on the HIR expression. This mitigates the performance regression discovered by the earlier perf-run. cc `@Kobzol` `@rylev` `@traviscross` I propose a `rust-timer` run to measure how much performance that we can recover from the mitigation. 🙇
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (748da1d): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 1.2%, secondary -0.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -0.9%, secondary -2.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 779.813s -> 778.613s (-0.15%) |
Looks like a GREAT SUCCESS to me. |
Looks great indeed :) I assume that there are tests that check that the lint does in fact fire during the edition migration? |
There is a test called A question to the t-compiler is, do we need a flag for this purpose? To be honest, only edition migration lints would be the potential users. Potentially lints for the match ergonomics and the async closures can benefit from the flag as well, because they are technically not executed outside the migration scenario. |
It looks like we need a look from someone on t-compiler to see this makes sense. Shall we? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused. Why do we need to manually call this here? Shouldn't lints automatically be filtering using lints_that_dont_need_to_run
? Isn't that the whole point of #125116?
I think we just need to remove the lint_level_at_node
call, right?
} | ||
if let (Level::Allow, _) = cx.tcx.lint_level_at_node(IF_LET_RESCOPE, expr.hir_id) { | ||
if expr.span.edition().at_least_rust_2024() | ||
|| cx.tcx.lints_that_dont_need_to_run(()).contains(&LintId::of(IF_LET_RESCOPE)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we even need this call to cx.tcx.lints_that_dont_need_to_run(())
? Aren't lints already automatically being filtered by the late lint infrastructure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently it is not, at least when I instrumented the fn check_expr
the log suggests that this lint was still called, which explains why the instruction count has increased significantly. I am looking for time to sit down and investigate why #125116 did not stop this lint from running.
@dingxiangfei2009 |
I looked into this. Yeah, we don't actually filter built-in lints. I think this is fine. @bors r+ rollup=never |
@bors p=5 (scheduling) |
☀️ Test successful - checks-actions |
Finished benchmarking commit (22a220a): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -0.7%, secondary 3.9%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -1.1%, secondary -2.7%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 776.719s -> 774.487s (-0.29%) |
Are there any other lints like this one that could also be skipped? :) |
This PR mostly just fixed a situation where a very specific Edition 2024 lint was executed everytime, even though it was not needed unless in migration mode (AFAIK). #125116 tried in general to not run lints that don't have to run (e.g. when they are allowed), but situations like these probably can't be detected by that. |
Note that #125116 does not filter out builtin lints which are lumped into the #134862 attempts to do some filtering in that pass, but it is probably not worth it -- the perf wins I think are just the wins from not running this pass. I'm re-running perf right now tho. |
Tracked by #124085
Related to #131984 (comment)
Given that
if-let-rescope
is a lint to be enabled globally by an edition migration, there is no point in extracting the precise lint level on the HIR expression. This mitigates the performance regression discovered by the earlier perf-run.cc @Kobzol @rylev @traviscross I propose a
rust-timer
run to measure how much performance that we can recover from the mitigation. 🙇