Infer async block return type from future expectation by compiler-errors · Pull Request #109338 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation4 Commits1 Checks0 Files changed
Conversation
This file contains hidden or 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
[ Show hidden characters]({{ revealButtonHref }})
Fixes #106527
r? types
This needs an FCP, since it makes async block return type inference stronger. This may have interactions with the new solver (since we want to avoid using pending obligations to do closure inference), but it's something that wg-async expects to work (#106527 (comment)). I'm ambivalent 😸
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
This comment has been minimized.
r? types
or unsure if this should be assigned to someone on the async wg
Contributor
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am worried about extending deduce_sig_from_projection as that uses nested obligations which we can't really support in the new solver.
I think this has the same issue we already have with closure inference? cc #108827
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
Status: Blocked on something else such as an RFC or other implementation work.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…ature-deduction, r=oli-obk
Implement async closure signature deduction
Self-explanatory from title.
Regarding the interaction between signature deduction, fulfillment, and the new trait solver: I'm not worried about implementing closure signature deduction here because:
- async closures are unstable, and
- I'm reasonably confident we'll need to support signature deduction in the new solver somehow (i.e. via proof trees, which seem very promising).
This is in contrast to rust-lang#109338, which was closed because it generalizes signature deduction for a stable kind of expression (async {} blocks and Future traits), and which proliferated usage may pose a stabilization hazard for the new solver.
I'll be certain to make sure sure we revisit the closure signature deduction problem by the time that async closures are being stabilized (which isn't particularly soon) (edit: Put it into the async closure tracking issue). cc @lcnr
r? @oli-obk
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…ature-deduction, r=oli-obk
Implement async closure signature deduction
Self-explanatory from title.
Regarding the interaction between signature deduction, fulfillment, and the new trait solver: I'm not worried about implementing closure signature deduction here because:
- async closures are unstable, and
- I'm reasonably confident we'll need to support signature deduction in the new solver somehow (i.e. via proof trees, which seem very promising).
This is in contrast to rust-lang#109338, which was closed because it generalizes signature deduction for a stable kind of expression (async {} blocks and Future traits), and which proliferated usage may pose a stabilization hazard for the new solver.
I'll be certain to make sure sure we revisit the closure signature deduction problem by the time that async closures are being stabilized (which isn't particularly soon) (edit: Put it into the async closure tracking issue). cc @lcnr
r? @oli-obk
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…ature-deduction, r=oli-obk
Implement async closure signature deduction
Self-explanatory from title.
Regarding the interaction between signature deduction, fulfillment, and the new trait solver: I'm not worried about implementing closure signature deduction here because:
- async closures are unstable, and
- I'm reasonably confident we'll need to support signature deduction in the new solver somehow (i.e. via proof trees, which seem very promising).
This is in contrast to rust-lang#109338, which was closed because it generalizes signature deduction for a stable kind of expression (async {} blocks and Future traits), and which proliferated usage may pose a stabilization hazard for the new solver.
I'll be certain to make sure sure we revisit the closure signature deduction problem by the time that async closures are being stabilized (which isn't particularly soon) (edit: Put it into the async closure tracking issue). cc @lcnr
r? @oli-obk
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…ature-deduction, r=oli-obk
Implement async closure signature deduction
Self-explanatory from title.
Regarding the interaction between signature deduction, fulfillment, and the new trait solver: I'm not worried about implementing closure signature deduction here because:
- async closures are unstable, and
- I'm reasonably confident we'll need to support signature deduction in the new solver somehow (i.e. via proof trees, which seem very promising).
This is in contrast to rust-lang#109338, which was closed because it generalizes signature deduction for a stable kind of expression (async {} blocks and Future traits), and which proliferated usage may pose a stabilization hazard for the new solver.
I'll be certain to make sure sure we revisit the closure signature deduction problem by the time that async closures are being stabilized (which isn't particularly soon) (edit: Put it into the async closure tracking issue). cc @lcnr
r? @oli-obk
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…ature-deduction, r=oli-obk
Implement async closure signature deduction
Self-explanatory from title.
Regarding the interaction between signature deduction, fulfillment, and the new trait solver: I'm not worried about implementing closure signature deduction here because:
- async closures are unstable, and
- I'm reasonably confident we'll need to support signature deduction in the new solver somehow (i.e. via proof trees, which seem very promising).
This is in contrast to rust-lang#109338, which was closed because it generalizes signature deduction for a stable kind of expression (async {} blocks and Future traits), and which proliferated usage may pose a stabilization hazard for the new solver.
I'll be certain to make sure sure we revisit the closure signature deduction problem by the time that async closures are being stabilized (which isn't particularly soon) (edit: Put it into the async closure tracking issue). cc @lcnr
r? @oli-obk
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#121857 - compiler-errors:async-closure-signature-deduction, r=oli-obk
Implement async closure signature deduction
Self-explanatory from title.
Regarding the interaction between signature deduction, fulfillment, and the new trait solver: I'm not worried about implementing closure signature deduction here because:
- async closures are unstable, and
- I'm reasonably confident we'll need to support signature deduction in the new solver somehow (i.e. via proof trees, which seem very promising).
This is in contrast to rust-lang#109338, which was closed because it generalizes signature deduction for a stable kind of expression (async {} blocks and Future traits), and which proliferated usage may pose a stabilization hazard for the new solver.
I'll be certain to make sure sure we revisit the closure signature deduction problem by the time that async closures are being stabilized (which isn't particularly soon) (edit: Put it into the async closure tracking issue). cc @lcnr
r? @oli-obk
Labels
Status: Blocked on something else such as an RFC or other implementation work.
Relevant to the compiler team, which will review and decide on the PR/issue.