-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Suggest desugaring to return-position impl Future
when an async fn
in trait fails an auto trait bound
#115864
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
r? @jackh726 (rustbot has picked a reviewer for you, use r? to override) |
Because of the changes to HIR @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Suggest desugaring to return-position `impl Future` when an `async fn` in trait fails an auto trait bound First commit allows us to store the span of the `async` keyword in HIR. Second commit implements a suggestion to desugar an `async fn` to a return-position `impl Future` in trait to slightly improve the `Send` situation being discussed in rust-lang#115822. This suggestion is only made when `#![feature(return_type_notation)]` is not enabled -- if it is, we should instead suggest an appropriate where-clause bound.
This comment has been minimized.
This comment has been minimized.
Of course because I'm developing on aarch64, I didn't see any of the type size changes. @rustbot author |
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
fe864be
to
733a447
Compare
@bors try @rust-timer queue |
Suggest desugaring to return-position `impl Future` when an `async fn` in trait fails an auto trait bound First commit allows us to store the span of the `async` keyword in HIR. Second commit implements a suggestion to desugar an `async fn` to a return-position `impl Future` in trait to slightly improve the `Send` situation being discussed in rust-lang#115822. This suggestion is only made when `#![feature(return_type_notation)]` is not enabled -- if it is, we should instead suggest an appropriate where-clause bound.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
// ... which is a local function | ||
let Some(fn_def_id) = fn_def_id.as_local() else { | ||
return; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we maybe mention that the problem lies in the trait definition so they know they have to bother the crate maintainer? Particularly thinking of the case of workspaces where the crate isn't local, but still under the dev's control.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I can do that. I can at least point to the async fn definition if we have a span for that.
compiler/rustc_trait_selection/src/traits/error_reporting/suggestions.rs
Show resolved
Hide resolved
compiler/rustc_trait_selection/src/traits/error_reporting/suggestions.rs
Show resolved
Hide resolved
Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred in src/librustdoc/clean/types.rs cc @camelid |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Suggest desugaring to return-position `impl Future` when an `async fn` in trait fails an auto trait bound First commit allows us to store the span of the `async` keyword in HIR. Second commit implements a suggestion to desugar an `async fn` to a return-position `impl Future` in trait to slightly improve the `Send` situation being discussed in rust-lang#115822. This suggestion is only made when `#![feature(return_type_notation)]` is not enabled -- if it is, we should instead suggest an appropriate where-clause bound.
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (bb4d374): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 633.484s -> 632.201s (-0.20%) |
fae8c23
to
2c3af4f
Compare
r? @estebank |
This comment has been minimized.
This comment has been minimized.
2c3af4f
to
9072415
Compare
Changes to the size of AST and/or HIR nodes. cc @nnethercote |
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (b3aa8e7): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 632.84s -> 634.138s (0.21%) |
It might be worth changing how that condition works, so that it hits for Mac M1 users. |
@nnethercote: unfortunately, can't do it the "simple" way by just enabling the |
I wonder what fraction of the existing size assertions have different results on aarch64 vs x86-64. |
First commit allows us to store the span of the
async
keyword in HIR.Second commit implements a suggestion to desugar an
async fn
to a return-positionimpl Future
in trait to slightly improve theSend
situation being discussed in #115822.This suggestion is only made when
#![feature(return_type_notation)]
is not enabled -- if it is, we should instead suggest an appropriate where-clause bound.