Inference of argument type of async closure is broken #127468
Labels
C-bug
Category: This is a bug.
Comments
kriomant
added
C-bug
rustbot
added
I-prioritize
|
This is a duplicate of #127425. Please rewrite your Or if you're passing an async closure to a library you do, then I recommend either ascribing the types of your arguments, or probably just change your |
saethlin
removed
I-prioritize
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Jul 8, 2024
…g-inference, r=oli-obk
Infer async closure signature from (old-style) two-part `Fn` + `Future` bounds
When an async closure is passed to a function that has a "two-part" `Fn` and `Future` trait bound, like:
```rust
use std::future::Future;
fn not_exactly_an_async_closure(_f: F)
where
F: FnOnce(String) -> Fut,
Fut: Future<Output = ()>,
{}
```
The we want to be able to extract the signature to guide inference in the async closure, like:
```rust
not_exactly_an_async_closure(async |string| {
for x in string.split('\n') { ... }
//~^ We need to know that the type of `string` is `String` to call methods on it.
})
```
Closure signature inference will see two bounds: `<?F as FnOnce<Args>>::Output = ?Fut`, `<?Fut as Future>::Output = String`. We need to extract the signature by looking through both projections.
### Why?
I expect the ecosystem's move onto `async Fn` trait bounds (which are not affected by this PR, and already do signature inference fine) to be slow. In the mean time, I don't see major overhead to supporting this "old–style" of trait bounds that were used to model async closures.
r? oli-obk
Fixes rust-lang#127468
Fixes rust-lang#127425
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 8, 2024
Rollup merge of rust-lang#127482 - compiler-errors:closure-two-par-sig-inference, r=oli-obk Infer async closure signature from (old-style) two-part `Fn` + `Future` bounds When an async closure is passed to a function that has a "two-part" `Fn` and `Future` trait bound, like: ```rust use std::future::Future; fn not_exactly_an_async_closure(_f: F) where F: FnOnce(String) -> Fut, Fut: Future<Output = ()>, {} ``` The we want to be able to extract the signature to guide inference in the async closure, like: ```rust not_exactly_an_async_closure(async |string| { for x in string.split('\n') { ... } //~^ We need to know that the type of `string` is `String` to call methods on it. }) ``` Closure signature inference will see two bounds: `<?F as FnOnce<Args>>::Output = ?Fut`, `<?Fut as Future>::Output = String`. We need to extract the signature by looking through both projections. ### Why? I expect the ecosystem's move onto `async Fn` trait bounds (which are not affected by this PR, and already do signature inference fine) to be slow. In the mean time, I don't see major overhead to supporting this "old–style" of trait bounds that were used to model async closures. r? oli-obk Fixes rust-lang#127468 Fixes rust-lang#127425
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Well, it is maybe not a regression technically, because I use unstable feature. However, I wouldn't like this to get into stable channel.
Code
I tried this code:
I expected to see this happen: I don't have to specify type of 'a' parameter as it may be inferred from
callsignature.Instead, this happened:
I did compiler bisection, here is the result:
The text was updated successfully, but these errors were encountered: