[EXPERIMENT] Rewrite closure-of-async to async-closure #127827
Closed
Conversation
This file contains 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
|
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
rustbot
added
S-waiting-on-review
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 16, 2024
…e-async, r=<try> [EXPERIMENT] Rewrite closure-of-async to async-closure to see what the fallout is uwuwuwu
This comment has been minimized.
This comment has been minimized.
|
☀️ Try build successful - checks-actions |
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
compiler-errors
force-pushed
the
async-closure-closure-async
branch
from
8f4f214
to
3851fe0
Compare
rustbot
added
the
WG-trait-system-refactor
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 25, 2024
…e-async, r=<try>
[EXPERIMENT] Rewrite closure-of-async to async-closure
to see what the fallout is, to gauge how forwards-compatible `async || {}` is w/ `|| async {}`.
uwuwuwu
This comment has been minimized.
This comment has been minimized.
|
☀️ Try build successful - checks-actions |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
@craterbot p=1 |
compiler-errors
force-pushed
the
async-closure-closure-async
branch
from
1b8ea65
to
61e2719
Compare
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 9, 2024
…e-async, r=<try>
[EXPERIMENT] Rewrite closure-of-async to async-closure
to see what the fallout is, to gauge how forwards-compatible `async || {}` is w/ `|| async {}`.
uwuwuwu
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 9, 2024
…e-async, r=<try>
[EXPERIMENT] Rewrite closure-of-async to async-closure
to see what the fallout is, to gauge how forwards-compatible `async || {}` is w/ `|| async {}`.
uwuwuwu
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
☀️ Try build successful - checks-actions |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
@craterbot p=1 since it's only 1k crates |
|
📝 Configuration of the ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Aug 15, 2024
…c-closure-inference, r=lcnr Infer async closure args from `Fn` bound even if there is no corresponding `Future` bound on return In rust-lang#127482, I implemented the functionality to infer an async closure signature when passed into a function that has `Fn` + `Future` where clauses that look like: ``` fn whatever(callback: F) where F: Fn(Arg) -> Fut, Fut: Future<Output = Out>, ``` However, rust-lang#127781 demonstrates that this is still incomplete to address the cases users care about. So let's not bail when we fail to find a `Future` bound, and try our best to just use the args from the `Fn` bound if we find it. This is *fine* since most users of closures only really care about the *argument* types for inference guidance, since we require the receiver of a `.` method call to be known in order to probe methods. When I experimented with programmatically rewriting `|| async {}` to `async || {}` in rust-lang#127827, this also seems to have fixed ~5000 regressions (probably all coming from usages `TryFuture`/`TryStream` from futures-rs): the [before](rust-lang#127827 (comment)) and [after](rust-lang#127827 (comment)) crater runs. Fixes rust-lang#127781.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 15, 2024
…c-closure-inference, r=lcnr Infer async closure args from `Fn` bound even if there is no corresponding `Future` bound on return In rust-lang#127482, I implemented the functionality to infer an async closure signature when passed into a function that has `Fn` + `Future` where clauses that look like: ``` fn whatever(callback: F) where F: Fn(Arg) -> Fut, Fut: Future<Output = Out>, ``` However, rust-lang#127781 demonstrates that this is still incomplete to address the cases users care about. So let's not bail when we fail to find a `Future` bound, and try our best to just use the args from the `Fn` bound if we find it. This is *fine* since most users of closures only really care about the *argument* types for inference guidance, since we require the receiver of a `.` method call to be known in order to probe methods. When I experimented with programmatically rewriting `|| async {}` to `async || {}` in rust-lang#127827, this also seems to have fixed ~5000 regressions (probably all coming from usages `TryFuture`/`TryStream` from futures-rs): the [before](rust-lang#127827 (comment)) and [after](rust-lang#127827 (comment)) crater runs. Fixes rust-lang#127781.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 15, 2024
Rollup merge of rust-lang#129072 - compiler-errors:more-powerful-async-closure-inference, r=lcnr Infer async closure args from `Fn` bound even if there is no corresponding `Future` bound on return In rust-lang#127482, I implemented the functionality to infer an async closure signature when passed into a function that has `Fn` + `Future` where clauses that look like: ``` fn whatever(callback: F) where F: Fn(Arg) -> Fut, Fut: Future<Output = Out>, ``` However, rust-lang#127781 demonstrates that this is still incomplete to address the cases users care about. So let's not bail when we fail to find a `Future` bound, and try our best to just use the args from the `Fn` bound if we find it. This is *fine* since most users of closures only really care about the *argument* types for inference guidance, since we require the receiver of a `.` method call to be known in order to probe methods. When I experimented with programmatically rewriting `|| async {}` to `async || {}` in rust-lang#127827, this also seems to have fixed ~5000 regressions (probably all coming from usages `TryFuture`/`TryStream` from futures-rs): the [before](rust-lang#127827 (comment)) and [after](rust-lang#127827 (comment)) crater runs. Fixes rust-lang#127781.
|
Basically done with this experiment |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
to see what the fallout is, to gauge how forwards-compatible
async || {}is w/|| async {}.uwuwuwu