Infer async block return type from future expectation#109338

compiler-errors · 2023-03-19T03:45:25Z

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 😸

spastorino · 2023-03-20T20:29:40Z

r? types

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

lcnr

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

compiler-errors · 2023-03-27T23:22:49Z

@rustbot blocked

…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`

…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``

…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```

…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````

…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`````

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`````

rustbot assigned spastorino Mar 19, 2023

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

This comment has been minimized.

Sign in to view

Infer async block return type from future expectation

7456253

compiler-errors force-pushed the async-deduce branch from a368fc3 to 7456253 Compare March 19, 2023 19:02

rustbot assigned lcnr and unassigned spastorino Mar 20, 2023

lcnr reviewed Mar 22, 2023

View reviewed changes

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

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

compiler-errors unassigned lcnr Mar 27, 2023

compiler-errors closed this May 19, 2023

Swatinem mentioned this pull request Jun 3, 2023

1.70.0: Type inference no longer works in conjunction with Glib's clone macro #112225

Closed

compiler-errors deleted the async-deduce branch August 11, 2023 19:55

compiler-errors mentioned this pull request Jan 12, 2024

Inline check_closure, simplify deduce_sig_from_projection #119900

Merged

compiler-errors mentioned this pull request Mar 1, 2024

Implement async closure signature deduction #121857

Merged

compiler-errors mentioned this pull request Mar 11, 2024

[async block]: Future<Output = Ty> obligations don't provide inference guidance #106527

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Infer async block return type from future expectation#109338