-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Compute lint_levels
by definition
#99634
Compute lint_levels
by definition
#99634
Conversation
r? @nagisa (rust-highfive has picked a reviewer for you, use r? to override) |
cc @xFrednet this touches impl for lint expectations |
r? rust-lang/compiler Not able to take on large reviews for the time being. |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 224cfded3fde57789375420501eb2146971eb807 with merge f2b76fa8b8a81c9059018568c196cf62f6ba4fdf... |
☀️ Try build successful - checks-actions |
Queued f2b76fa8b8a81c9059018568c196cf62f6ba4fdf with parent c32dcbb, future comparison URL. |
Finished benchmarking commit (f2b76fa8b8a81c9059018568c196cf62f6ba4fdf): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Footnotes |
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.
Not exceptionally familiar with the lint level computation but this seems reasonable (when not considering the big perf regression), will re-assign to cjgillot though.
r? @cjgillot |
Yeah, I'm going to need some help regarding the perf hits here. @cjgillot could you take a look? Thanks. |
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.
You caught a bad case of incremental compilation invalidation.
When the incr. comp. engine tries to mark a query as green, it first checks whether all its dependencies are green. lint_levels_on
depends on resolutions
, which is always red.
As it can trivially mark lint_levels_on
as green, the incr. comp. engine tries to recompute the query. The query takes a HirId
but the incr. comp. engine does not know how to make a HirId
from its Fingerprint
. So it cannot recompute the query, and marks lint_levels_on
as red.
As a consequence, all queries that call it (= pretty much everything) get recomputed.
There are 2 possibilities here:
- compute
lint_levels_on
by definition: for a whole item/trait-item/impl-item/foreign-item at once, and makelint_levels_on
take aLocalDefId
; - teach the query system to force a query that takes a
HirId
.
(1) may need to a larger refactor of the levels computation. It will avoid the query call overhead (there are many more HirId
s that LocalDefId
s), but that overhead only appears as a ~1% regression, so that's probably fine.
(2) is a bit more experimental. For this, you need to:
- add a variant to
rustc_query_system::dep_graph::FingerprintStyle
; - return it in the
<HirId as DepNodeParams>::fingerprint_style
inrustc_middle::dep_graph::dep_node
; - modify
to_fingerprint
andrecover
in that method have a bidirectional conversionFingerprint <-> HirId
(look at whatLocalDefId
does for instance).
224cfde
to
4e32372
Compare
rebase; no work yet |
☔ The latest upstream changes (presumably #100426) made this pull request unmergeable. Please resolve the merge conflicts. |
4e32372
to
0899c7c
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #101064) made this pull request unmergeable. Please resolve the merge conflicts. |
… r=oli-obk Compute lint levels by definition Lint levels are currently computed once for the whole crate. Any code that wants to emit a lint depends on this single `lint_levels(())` query. This query contains the `Span` for each attribute that participates in the lint level tree, so any code that wants to emit a lint basically depends on the spans in all files in the crate. Contrary to hard errors, we do not clear the incremental session on lints, so this implicit world dependency pessimizes incremental reuse. (And is furthermore invisible for allowed lints.) This PR completes rust-lang#99634 (thanks for the initial work `@fee1-dead)` and includes it in the dependency graph. The design is based on 2 queries: 1. `lint_levels_on(HirId) -> FxHashMap<LintId, LevelAndSource>` which accesses the attributes at the given `HirId` and processes them into lint levels. The `TyCtxt` is responsible for probing the HIR tree to find the user-visible level. 2. `lint_expectations(())` which lists all the `#[expect]` attributes in the crate. This PR also introduces the ability to reconstruct a `HirId` from a `DepNode` by encoding the local part of the `DefPathHash` and the `ItemLocalId` in the two `u64` of the fingerprint. This allows for the dep-graph to directly recompute `lint_levels_on` directly, without having to force the calling query. Closes rust-lang#95094. Supersedes rust-lang#99634.
Closes #95094.
cc @cjgillot