Encode synthetic by-move coroutine body with a different DefPathData
#139153
+64
−29
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
A-query-system
|
Some changes occurred in compiler/rustc_sanitizers cc @rust-lang/project-exploit-mitigations, @rcvalle |
|
r? @oli-obk perhaps |
compiler-errors
changed the title
DefPathData
This comment has been minimized.
This comment has been minimized.
compiler-errors
force-pushed
the
incr-comp-closure
branch
from
773daad to
897acc3
Compare
|
Some changes occurred in coverage tests. cc @Zalathar |
|
Amazing @bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 31, 2025
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#138176 (Prefer built-in sized impls (and only sized impls) for rigid types always) - rust-lang#138749 (Fix closure recovery for missing block when return type is specified) - rust-lang#138842 (Emit `unused_attributes` for `#[inline]` on exported functions) - rust-lang#139153 (Encode synthetic by-move coroutine body with a different `DefPathData`) - rust-lang#139157 (Remove mention of `exhaustive_patterns` from `never` docs) - rust-lang#139167 (Remove Amanieu from the libs review rotation) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 31, 2025
Rollup merge of rust-lang#139153 - compiler-errors:incr-comp-closure, r=oli-obk Encode synthetic by-move coroutine body with a different `DefPathData` See the included test. In the first revision rpass1, we have an async closure `{closure#0}` which has a coroutine as a child `{closure#0}::{closure#0}`. We synthesize a by-move coroutine body, which is `{closure#0}::{closure#1}` which depends on the mir_built query, which depends on the typeck query. In the second revision rpass2, we've replaced the coroutine-closure by a closure with two children closure. Notably, the def path of the second child closure is the same as the synthetic def id from the last revision: `{closure#0}::{closure#1}`. When type-checking this closure, we end up trying to compute its def_span, which tries to fetch it from the incremental cache; this will try to force the dependencies from the last run, which ends up forcing the mir_built query, which ends up forcing the typeck query, which ends up with a query cycle. The problem here is that we really should never have used the same `DefPathData` for the synthetic by-move coroutine body, since it's not a closure. Changing the `DefPathData` will mean that we can see that the def ids are distinct, which means we won't try to look up the closure's def span from the incremental cache, which will properly skip replaying the node's dependencies and avoid a query cycle. Fixes rust-lang#139142
|
Bors thinks this is still in the queue: @bors r- |
bors
added
S-waiting-on-author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See the included test. In the first revision rpass1, we have an async closure
{closure#0}which has a coroutine as a child{closure#0}::{closure#0}. We synthesize a by-move coroutine body, which is{closure#0}::{closure#1}which depends on the mir_built query, which depends on the typeck query.In the second revision rpass2, we've replaced the coroutine-closure by a closure with two children closure. Notably, the def path of the second child closure is the same as the synthetic def id from the last revision:
{closure#0}::{closure#1}. When type-checking this closure, we end up trying to compute its def_span, which tries to fetch it from the incremental cache; this will try to force the dependencies from the last run, which ends up forcing the mir_built query, which ends up forcing the typeck query, which ends up with a query cycle.The problem here is that we really should never have used the same
DefPathDatafor the synthetic by-move coroutine body, since it's not a closure. Changing theDefPathDatawill mean that we can see that the def ids are distinct, which means we won't try to look up the closure's def span from the incremental cache, which will properly skip replaying the node's dependencies and avoid a query cycle.Fixes #139142