Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Check coroutine upvars and resume ty 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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
compiler-errors wants to merge1 commit intorust-lang:master
base:master
Choose a base branch
Loading
fromcompiler-errors:dtorck-upvars

Conversation

compiler-errors
Copy link
Member

@compiler-errorscompiler-errors commentedJul 18, 2025
edited by rustbot
Loading

Fix for#144155.

r?@lcnr or reassign 😸


Just some thoughts --- a proper fix for this whole situation would be to considerTypingMode in theneeds_drop call, and just callingcoroutine_ty.needs_drop() 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 stallall coroutines in analysis mode. Then in borrowck mode, we can re-checkneeds_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.

@rustbotrustbot added S-waiting-on-reviewStatus: Awaiting review from the assignee but also interested parties. T-compilerRelevant to the compiler team, which will review and decide on the PR/issue. labelsJul 18, 2025
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees

@lcnrlcnr

Labels
S-waiting-on-reviewStatus: Awaiting review from the assignee but also interested parties.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

3 participants
@compiler-errors@lcnr@rustbot

[8]ページ先頭

©2009-2025 Movatter.jp