Skip to content

Check coroutine upvars in dtorck constraint #144156

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

Merged
merged 2 commits into from
Aug 11, 2025

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Jul 18, 2025

Fix #144155.

This PR fixes an unsoundness where we were not considering coroutine upvars as drop-live if the coroutine interior types (witness types) had nothing which required drop.

In the case that the coroutine does not have any interior types that need to be dropped, then we don't need to treat all of the upvars as use-live; instead, this PR uses the same logic as closures, and descends into the upvar types to collect anything that must be drop-live. The rest of this PR is reworking the comment to explain the behavior here.

r? @lcnr or reassign 😸


Just some thoughts --- a proper fix for this whole situation would be to consider TypingMode in the needs_drop function, and just calling coroutine_ty.needs_drop(tcx, typing_env) in the dtorck constraint check.

During MIR building, we should probably use a typing mode that stalls the local coroutines and considers them to be unconditionally drop, or perhaps just stall all coroutines in analysis mode. Then in borrowck mode, we can re-check needs_drop but descend into witness types properly. #144158 implements this experimentally.

This is a pretty involved fix, and conflicts with some in-flight changes (#144157) that I have around removing coroutine witnesses altogether. I'm happy to add a FIXME to rework this whole approach, but I don't want to block this quick fix since it's obviously more correct than the status-quo.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 18, 2025
@compiler-errors
Copy link
Member Author

Yeah, I guess the resume ty doesn't need to be checked since although it can contain lifetimes, it would need to be stored in a witness ty to actually be dropped (since it doesn't have its own storage) and so it's redundant wrt the witness part of this drop check.

@compiler-errors compiler-errors changed the title Check coroutine upvars and resume ty in dtorck constraint Check coroutine upvars in dtorck constraint Jul 21, 2025
@compiler-errors compiler-errors force-pushed the dtorck-upvars branch 2 times, most recently from bde52d9 to a6cc0fe Compare July 21, 2025 15:41
@compiler-errors
Copy link
Member Author

Tweaked the comment a bit more and implemented the modified check that only requires the upvars be drop-live if there are no drops in the interior.

@compiler-errors
Copy link
Member Author

Also tweaked this comment to use "interior" rather than flopping between "witness" and "interior". TBH i kinda prefer that name over witness, and at least for the purposes of this explanation it makes it clear that it's types that are local to the body of the coroutine.

@compiler-errors
Copy link
Member Author

Also added a test for the upvar breakage.

@lcnr lcnr added T-types Relevant to the types team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 22, 2025
@lcnr
Copy link
Contributor

lcnr commented Jul 22, 2025

Hi @rust-lang/types, I previously assumed that every type stored in a coroutine is part of its witness. This assumption caused us to only require things to be live when dropping the coroutine if the witness required drop in #117134.

This is not the case as we may capture upvars by value. These upvars are not considered part of the witness, but still need to get dropped when dropping the coroutine. This PR updates the comment to better explain what's going on and fixes this issue.

We now require all upvars to be drop-live regardless of whether the coroutine witness has anything that needs to be drop.

@rfcbot fcp merge

I think we should still do a crater run?

@rfcbot
Copy link
Collaborator

rfcbot commented Jul 22, 2025

Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jul 22, 2025
@oli-obk
Copy link
Contributor

oli-obk commented Jul 22, 2025

@bors2 try

@rust-bors
Copy link

rust-bors bot commented Jul 22, 2025

⌛ Trying commit 9b0b433 with merge c4ca246

To cancel the try build, run the command @bors2 try cancel.

rust-bors bot added a commit that referenced this pull request Jul 22, 2025
Check coroutine upvars in dtorck constraint
@rust-bors
Copy link

rust-bors bot commented Jul 22, 2025

☀️ Try build successful (CI)
Build commit: c4ca246 (c4ca24658d934444a28db36abebef17a8651701a, parent: 9748d87dc70a9a6725c5dbd76ce29d04752b4f90)

@lcnr
Copy link
Contributor

lcnr commented Jul 22, 2025

@craterbot check

@craterbot
Copy link
Collaborator

👌 Experiment pr-144156 created and queued.
🤖 Automatically detected try build c4ca246
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Jul 29, 2025
@rfcbot
Copy link
Collaborator

rfcbot commented Jul 29, 2025

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Jul 29, 2025
@bors
Copy link
Collaborator

bors commented Aug 2, 2025

☔ The latest upstream changes (presumably #144458) made this pull request unmergeable. Please resolve the merge conflicts.

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Aug 8, 2025
@rfcbot
Copy link
Collaborator

rfcbot commented Aug 8, 2025

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@lcnr
Copy link
Contributor

lcnr commented Aug 8, 2025

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 8, 2025
@compiler-errors
Copy link
Member Author

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 8, 2025
@lcnr
Copy link
Contributor

lcnr commented Aug 11, 2025

@bors r+

@bors
Copy link
Collaborator

bors commented Aug 11, 2025

📌 Commit 560e5dc has been approved by lcnr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 11, 2025
bors added a commit that referenced this pull request Aug 11, 2025
Rollup of 5 pull requests

Successful merges:

 - #135331 (Reject relaxed bounds inside associated type bounds (ATB))
 - #144156 (Check coroutine upvars in dtorck constraint)
 - #145091 (`NllRegionVariableOrigin` remove `from_forall`)
 - #145194 (Ignore coroutine witness type region args in auto trait confirmation)
 - #145225 (Fix macro infinite recursion test to not trigger warning about semicolon in expr)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 4e87b74 into rust-lang:master Aug 11, 2025
10 checks passed
@rustbot rustbot added this to the 1.91.0 milestone Aug 11, 2025
rust-timer added a commit that referenced this pull request Aug 11, 2025
Rollup merge of #144156 - compiler-errors:dtorck-upvars, r=lcnr

Check coroutine upvars in dtorck constraint

Fix #144155.

This PR fixes an unsoundness where we were not considering coroutine upvars as drop-live if the coroutine interior types (witness types) had nothing which required drop.

In the case that the coroutine does not have any interior types that need to be dropped, then we don't need to treat all of the upvars as use-live; instead, this PR uses the same logic as closures, and descends into the upvar types to collect anything that must be drop-live. The rest of this PR is reworking the comment to explain the behavior here.

r? `@lcnr` or reassign 😸

---

Just some thoughts --- a proper fix for this whole situation would be to consider `TypingMode` in the `needs_drop` function, and just calling `coroutine_ty.needs_drop(tcx, typing_env)` in the dtorck constraint check.

During MIR building, we should probably use a typing mode that stalls the local coroutines and considers them to be unconditionally drop, or perhaps just stall *all* coroutines in analysis mode. Then in borrowck mode, we can re-check `needs_drop` but descend into witness types properly. #144158 implements this experimentally.

This is a pretty involved fix, and conflicts with some in-flight changes (#144157) that I have around removing coroutine witnesses altogether. I'm happy to add a FIXME to rework this whole approach, but I don't want to block this quick fix since it's obviously more correct than the status-quo.
@bors
Copy link
Collaborator

bors commented Aug 11, 2025

⌛ Testing commit 560e5dc with merge 5771665...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-types Relevant to the types team, which will review and decide on the PR/issue. to-announce Announce this issue on triage meeting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Coroutine upvars are not required to be live in borrowck if witness has no drop requirements
8 participants