Infer async closure args from Fn bound even if there is no corresponding Future bound on return#129072
Merged
bors merged 1 commit intorust-lang:masterfrom Aug 15, 2024
Conversation
Collaborator
|
r? @nnethercote rustbot has assigned @nnethercote. Use |
Contributor
|
I'm not a good person to review a PR involving types and a "SUBTLE" comment :) r? @lcnr |
5a022a3 to
84d6723
Compare
lcnr
reviewed
Aug 14, 2024
Comment on lines
+589
to
+597
| let return_ty = | ||
| return_ty.unwrap_or_else(|| self.next_ty_var(cause_span.unwrap_or(DUMMY_SP))); |
Contributor
There was a problem hiding this comment.
why directly use the input_tys but create a new infer var for the return type? You could also reuse that one, can't u
Contributor
Author
There was a problem hiding this comment.
The return type vid that is in scope is the type of the future, but we want the type of the future's output. We don't have it, so we need to make a new type var here.
Contributor
|
@rustbot author |
84d6723 to
4290943
Compare
Contributor
|
@bors r+ rollup |
Collaborator
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.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 15, 2024
…llaumeGomez Rollup of 8 pull requests Successful merges: - rust-lang#128348 (Unconditionally allow shadow call-stack sanitizer for AArch64) - rust-lang#128922 (rust-analyzer: use in-tree `pattern_analysis` crate) - rust-lang#128935 (More work on `zstd` compression) - rust-lang#129072 (Infer async closure args from `Fn` bound even if there is no corresponding `Future` bound on return) - rust-lang#129101 (Fix projections when parent capture is by-ref but child capture is by-value in the `ByMoveBody` pass) - rust-lang#129106 (Remove redundant type ops: `Eq`/`Subtype`) - rust-lang#129122 (Remove duplicated `Rustdoc::output` method from `run-make-support` lib) - rust-lang#129124 (rustdoc-json: Use FxHashMap from rustdoc_json_types) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 15, 2024
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#128348 (Unconditionally allow shadow call-stack sanitizer for AArch64) - rust-lang#129065 (Use `impl PartialEq<TokenKind> for Token` more.) - rust-lang#129072 (Infer async closure args from `Fn` bound even if there is no corresponding `Future` bound on return) - rust-lang#129096 (Print more verbose error for commands that capture output) - rust-lang#129101 (Fix projections when parent capture is by-ref but child capture is by-value in the `ByMoveBody` pass) - rust-lang#129106 (Remove redundant type ops: `Eq`/`Subtype`) - rust-lang#129122 (Remove duplicated `Rustdoc::output` method from `run-make-support` lib) - rust-lang#129124 (rustdoc-json: Use FxHashMap from rustdoc_json_types) r? `@ghost` `@rustbot` modify labels: rollup
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.
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
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.
In #127482, I implemented the functionality to infer an async closure signature when passed into a function that has
Fn+Futurewhere clauses that look like:However, #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
Futurebound, and try our best to just use the args from theFnbound 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 {}toasync || {}in #127827, this also seems to have fixed ~5000 regressions (probably all coming from usagesTryFuture/TryStreamfrom futures-rs): the before and after crater runs.Fixes #127781.