Skip to content

Infer async block return type from future expectation #109338

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

Infer async block return type from future expectation #109338

wants to merge 1 commit into from

Conversation

compiler-errors
Copy link
Member

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 😸

@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 Mar 19, 2023
@rust-log-analyzer

This comment has been minimized.

# to view
@spastorino
Copy link
Member

r? types

or unsure if this should be assigned to someone on the async wg

@rustbot rustbot assigned lcnr and unassigned spastorino Mar 20, 2023
lcnr
lcnr reviewed Mar 22, 2023
View reviewed changes
Copy link
Contributor

@lcnr lcnr left a comment

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

@lcnr lcnr 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 Mar 22, 2023
@compiler-errors
Copy link
Member Author

@rustbot blocked

@rustbot rustbot added S-blocked 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 Mar 27, 2023
@Swatinem Swatinem mentioned this pull request Jun 3, 2023
Closed
@compiler-errors compiler-errors deleted the async-deduce branch August 11, 2023 19:55
@compiler-errors compiler-errors mentioned this pull request Jan 12, 2024
Merged
@compiler-errors compiler-errors mentioned this pull request Mar 1, 2024
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 5, 2024
@matthiaskrgr
Rollup merge of rust-lang#121857 - compiler-errors:async-closure-sign…
2614564 
…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:

1. async closures are unstable, and
2. 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 Mar 5, 2024
@matthiaskrgr
Rollup merge of rust-lang#121857 - compiler-errors:async-closure-sign…
360d17a 
…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:

1. async closures are unstable, and
2. 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 Mar 5, 2024
@matthiaskrgr
Rollup merge of rust-lang#121857 - compiler-errors:async-closure-sign…
28e3fc4 
…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:

1. async closures are unstable, and
2. 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 Mar 5, 2024
@matthiaskrgr
Rollup merge of rust-lang#121857 - compiler-errors:async-closure-sign…
d54254e 
…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:

1. async closures are unstable, and
2. 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 Mar 5, 2024
@matthiaskrgr
Rollup merge of rust-lang#121857 - compiler-errors:async-closure-sign…
2875b10 
…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:

1. async closures are unstable, and
2. 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 Mar 6, 2024
@rust-timer
Unrolled build for rust-lang#121857
7806e0f 
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:

1. async closures are unstable, and
2. 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`````
@compiler-errors compiler-errors mentioned this pull request Mar 11, 2024
Open
# for free to join this conversation on GitHub. Already have an account? # to comment
Reviewers

@lcnr lcnr lcnr left review comments

Assignees
No one assigned
Labels
S-blocked Status: Blocked on something else such as an RFC or other implementation work. T-compiler Relevant 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.

[async block]: Future<Output = Ty> obligations don't provide inference guidance
5 participants
@compiler-errors @rust-log-analyzer @spastorino @lcnr @rustbot