-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Tighten fn_decl_span
for async blocks
#127058
Conversation
LL | | game_loop(Arc::clone(&room_ref)) | ||
| | -------- `room_ref` is borrowed here | ||
LL | | }); | ||
| |_____^ may outlive borrowed value `room_ref` |
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.
Here's the only place that the diagnostic arguably got worse. I kinda don't think it matters, though, because the primary message still says:
async block may outlive the current function, but it borrows
room_ref
, which is owned by the current function
So it's still clear that the problem is with an async block.
If you care enough about this for it to get fixed, then I suggest we change the label to state what may outlive the borrowed value, i.e.:
LL | let gameloop_handle = spawn(async {
| ^^^^^ async block may outlive borrowed value `room_ref`
This comment has been minimized.
This comment has been minimized.
696e2ed
to
789ee88
Compare
Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt |
@@ -8,7 +8,7 @@ LL | let f: F = async { 1 }; | |||
= help: add `#![feature(const_async_blocks)]` to the crate attributes to enable | |||
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date | |||
|
|||
error[E0271]: expected `{async block@$DIR/issue-78722.rs:10:13: 10:21}` to be a future that resolves to `u8`, but it resolves to `()` | |||
error[E0271]: expected `{async block@$DIR/issue-78722.rs:10:13: 10:18}` to be a future that resolves to `u8`, but it resolves to `()` |
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.
Note to self: we should special case the wording here to be something like
error[E0271]: expected `{async block@$DIR/issue-78722.rs:10:13: 10:18}` to be a future that resolves to `u8`, but it resolves to `()` | |
error[E0271]: expected async block to be a future that resolves to `u8`, but it resolves to `()` |
error[E0277]: `{gen block@$DIR/gen_block_is_no_future.rs:5:5: 5:8}` is not a future | ||
--> $DIR/gen_block_is_no_future.rs:4:13 | ||
| | ||
LL | fn foo() -> impl std::future::Future { | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^ `{gen block@$DIR/gen_block_is_no_future.rs:5:5: 5:21}` is not a future | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^ `{gen block@$DIR/gen_block_is_no_future.rs:5:5: 5:8}` is not a future | ||
| | ||
= help: the trait `Future` is not implemented for `{gen block@$DIR/gen_block_is_no_future.rs:5:5: 5:21}` | ||
= help: the trait `Future` is not implemented for `{gen block@$DIR/gen_block_is_no_future.rs:5:5: 5:8}` |
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.
We need to figure out how to point at the gen/async block in E0277s because the error as is isn't as clear as it should be: we point at the span that introduced the obligation, not where the obligation wasn't fulfilled.
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.
This is a general problem with opaques.
we point at the span that introduced the obligation
This is the span that introduces the obligation. You're thinking about the span that introduces the expression that assigns the hidden type of the opaque. Determining what that span is is difficult to impossible without hacks that I would rather not try to land, because they will almost certainly regress with the new solver.
@@ -13,7 +13,7 @@ note: captured value is not `Send` because `&` references cannot be sent unless | |||
| | |||
LL | let x = x; | |||
| ^ has type `&T` which is not `Send`, because `T` is not `Sync` | |||
= note: required for the cast from `Pin<Box<{async block@$DIR/issue-86507.rs:18:17: 20:18}>>` to `Pin<Box<(dyn Future<Output = ()> + Send + 'async_trait)>>` | |||
= note: required for the cast from `Pin<Box<{async block@$DIR/issue-86507.rs:18:17: 18:27}>>` to `Pin<Box<(dyn Future<Output = ()> + Send + 'async_trait)>>` |
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.
Going through all of there errors, I wonder if mentioning the end of the span is necessary in messages...
LL | (async move || { | ||
| - return type of async closure is &'1 i32 | ||
... | ||
LL | let y = &*x; | ||
| --- `*x` is borrowed here | ||
LL | *x += 1; | ||
| ^^^^^^^ `*x` is assigned to here but it was already borrowed | ||
LL | y | ||
| - returning this value requires that `*x` is borrowed for `'1` | ||
LL | })() | ||
| - return type of async closure is &'1 i32 |
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.
<3
LL | needs_async_fn(async || { | ||
| -------------- ^^^^^^^^ | ||
| | | | ||
| | cannot borrow as mutable | ||
| | in this closure | ||
| expects `Fn` instead of `FnMut` |
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.
Maybe we should now remove the "in this closure" label, as it is no longer relevant?
…s, r=oli-obk Tighten `fn_decl_span` for async blocks Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on rust-lang#125078, but it fixes the problem in a more general way. I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters. r? `@estebank` or `@oli-obk` or someone else on wg-diag or compiler i dont really care lol
…s, r=oli-obk Tighten `fn_decl_span` for async blocks Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on rust-lang#125078, but it fixes the problem in a more general way. I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters. r? ``@estebank`` or ``@oli-obk`` or someone else on wg-diag or compiler i dont really care lol
…s, r=oli-obk Tighten `fn_decl_span` for async blocks Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on rust-lang#125078, but it fixes the problem in a more general way. I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters. r? ```@estebank``` or ```@oli-obk``` or someone else on wg-diag or compiler i dont really care lol
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#124741 (patchable-function-entry: Add unstable compiler flag and attribute) - rust-lang#126470 (make cargo submodule optional) - rust-lang#126701 (ignore `llvm::Lld` if lld is not enabled) - rust-lang#126956 (core: avoid `extern type`s in formatting infrastructure) - rust-lang#126970 (Simplify `str::clone_into`) - rust-lang#127058 (Tighten `fn_decl_span` for async blocks) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#124741 (patchable-function-entry: Add unstable compiler flag and attribute) - rust-lang#126470 (make cargo submodule optional) - rust-lang#126956 (core: avoid `extern type`s in formatting infrastructure) - rust-lang#126970 (Simplify `str::clone_into`) - rust-lang#127022 (Support fetching `Attribute` of items.) - rust-lang#127058 (Tighten `fn_decl_span` for async blocks) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#127058 - compiler-errors:tighten-async-spans, r=oli-obk Tighten `fn_decl_span` for async blocks Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on rust-lang#125078, but it fixes the problem in a more general way. I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters. r? ````@estebank```` or ````@oli-obk```` or someone else on wg-diag or compiler i dont really care lol
…s, r=oli-obk Tighten `fn_decl_span` for async blocks Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on rust-lang#125078, but it fixes the problem in a more general way. I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters. r? ````@estebank```` or ````@oli-obk```` or someone else on wg-diag or compiler i dont really care lol
Tightens the span of
async {}
blocks in diagnostics, and subsequently async closures and async fns, by actually setting thefn_decl_span
correctly. This is kinda a follow-up on #125078, but it fixes the problem in a more general way.I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters.
r? @estebank or @oli-obk or someone else on wg-diag or compiler i dont really care lol