fix: avoid panic in malformed async closures - #23116
Conversation
Probably GitHub got confused thinking they're HTML tags. You can replace them with |
This comment has been minimized.
This comment has been minimized.
af8bedf to
0c786f2
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
I found synthetic moves (e.g. let b = b;) in async closure lowering cause HIR paths (resolved by name only) to mismatch formal bindings, breaking child capture vs num_args check.Maybe this is the root cause of the problem. |
0c786f2 to
8860283
Compare
|
Paths generated by async closure lowering can only be resolved by name and hygiene. When parameters have the same name, the generated let b = b may resolve to the wrong binding, destroying the parameter order of coroutine capture. |
|
No, |
8860283 to
98ce9b2
Compare
|
Now it only creates internal unique names for subsequent conflicting parameters when rust-analyzer performs error recovery on illegal duplicate async-closure parameters to avoid capture/type inference panics due to misaligned binding identities. |
I don’t know why formatting swallows my ai translated content marked with <> :(
So I express the repair content in my own words:
Original implementation skipped the number of parameters capture . So I fix to determine capture ownership based on the binding owner.
Fix: #22821