Skip to content

fix: avoid panic in malformed async closures - #23116

Open
YUZHEthefool wants to merge 1 commit into
rust-lang:masterfrom
YUZHEthefool:fix-22821-async-closure-captures
Open

fix: avoid panic in malformed async closures#23116
YUZHEthefool wants to merge 1 commit into
rust-lang:masterfrom
YUZHEthefool:fix-22821-async-closure-captures

Conversation

@YUZHEthefool

@YUZHEthefool YUZHEthefool commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

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

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 11, 2026
@ChayimFriedman2

Copy link
Copy Markdown
Contributor

I don’t know why formatting swallows my ai translated content marked with <>

Probably GitHub got confused thinking they're HTML tags. You can replace them with &lt; and &gt;.

@ChayimFriedman2 ChayimFriedman2 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is copied from rustc so I heavily doubt it's where the bug is. The bug is probably is some other code that this code consumes its output.

View changes since this review

@rustbot

This comment has been minimized.

@YUZHEthefool
YUZHEthefool force-pushed the fix-22821-async-closure-captures branch from af8bedf to 0c786f2 Compare August 11, 2026 14:24
@rustbot

rustbot commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

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.

@YUZHEthefool

Copy link
Copy Markdown
Contributor Author

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.

@ChayimFriedman2 ChayimFriedman2 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the code is still incorrect. The synthetic names should be there.

View changes since this review

@YUZHEthefool
YUZHEthefool force-pushed the fix-22821-async-closure-captures branch from 0c786f2 to 8860283 Compare August 11, 2026 16:59
@YUZHEthefool

Copy link
Copy Markdown
Contributor Author

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.
Im not sure if this is the real way,maybe I should think about this tomorrow

@ChayimFriedman2

Copy link
Copy Markdown
Contributor

No, let b = b shadows an existing b and resolves to it. This is normal in Rust.

@YUZHEthefool
YUZHEthefool force-pushed the fix-22821-async-closure-captures branch from 8860283 to 98ce9b2 Compare August 12, 2026 06:19
@YUZHEthefool

Copy link
Copy Markdown
Contributor Author

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 did confuse the issue in yesterday's commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

panic: we captured CapturedPlace

3 participants