-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
Improve move error diagnostic for AsyncFn closures
#150572
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
Improve move error diagnostic for AsyncFn closures
#150572
Conversation
This comment has been minimized.
This comment has been minimized.
d65f71a to
9ef09ef
Compare
|
@rustbot reroll Hopefully another reviewer will have better knowledge about #150572 (comment) |
This comment was marked as outdated.
This comment was marked as outdated.
9ef09ef to
d6a8c72
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment has been minimized.
This comment has been minimized.
48c7d9e to
0f81d39
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
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.
nit, then r=me
0f81d39 to
5088318
Compare
|
after nit @bors delegate+ |
|
✌️ @heathdutton, you can now approve this pull request! If @lcnr told you to " |
When an async closure captures a variable by move but is constrained to `AsyncFn` or `AsyncFnMut`, the error message now explains that the closure kind is the issue and points to the trait bound, similar to the existing diagnostic for `Fn`/`FnMut` closures.
5088318 to
f5f2ca0
Compare
|
@bors r=lcnr |
…iagnostic-v2, r=lcnr
Improve move error diagnostic for `AsyncFn` closures
When an async closure captures a variable by move but is constrained to `AsyncFn` or `AsyncFnMut`, the error message now explains that the closure kind is the issue and points to the trait bound, similar to the existing diagnostic for `Fn`/`FnMut` closures.
**Before:**
```
error[E0507]: cannot move out of `foos` which is behind a shared reference
--> src/lib.rs:12:20
|
11 | async fn foo(foos: &mut [&mut Foo]) -> Result<(), ()> {
| ---- move occurs because `foos` has type...
12 | in_transaction(async || -> Result<(), ()> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ `foos` is moved here
13 | for foo in foos {
| ---- variable moved due to use in coroutine
```
**After:**
```
error[E0507]: cannot move out of `y`, a captured variable in an `AsyncFn` closure
--> src/lib.rs:9:10
|
LL | let y = vec![format!("World")];
| - captured outer variable
LL | call(async || {
| ^^^^^^^^ captured by this `AsyncFn` closure
...
help: `AsyncFn` and `AsyncFnMut` closures require captured values to be able
to be consumed multiple times, but `AsyncFnOnce` closures may consume
them only once
--> src/lib.rs:5:27
|
LL | fn call<F>(_: F) where F: AsyncFn() {}
| ^^^^^^^^^
```
Fixes rust-lang#150174
Rollup of 8 pull requests Successful merges: - #150474 (Tidy: detect ui tests subdirectory changes so `tests/ui/README.md` stays in sync) - #150572 (Improve move error diagnostic for `AsyncFn` closures) - #151596 (Fix -Zmir-enable-passes to detect unregistered enum names in declare_passes macro) - #151802 (Make `QueryDispatcher::Qcx` an associated type) - #151559 ([rustdoc] Add a marker to tell users that there are hidden (deprecated) items in the search results) - #151665 (Fix contrast ratio for `Since` element in rustodoc dark theme) - #151798 (Update `askama` to `0.15.3`) - #151800 (Subscribe myself to translation diagnostics)
Rollup of 12 pull requests Successful merges: - #150474 (Tidy: detect ui tests subdirectory changes so `tests/ui/README.md` stays in sync) - #150572 (Improve move error diagnostic for `AsyncFn` closures) - #151596 (Fix -Zmir-enable-passes to detect unregistered enum names in declare_passes macro) - #151802 (Make `QueryDispatcher::Qcx` an associated type) - #149110 (Implement `cast_slice` for raw pointer types) - #151559 ([rustdoc] Add a marker to tell users that there are hidden (deprecated) items in the search results) - #151665 (Fix contrast ratio for `Since` element in rustdoc dark theme) - #151785 (Stabilize feature(push_mut)) - #151798 (Update `askama` to `0.15.3`) - #151800 (Subscribe myself to translation diagnostics) - #151804 (Document, sort, and tweak spellcheck entries in `typos.toml`) - #151805 (Fix grammar in `env::current_exe()#Security`)
Rollup merge of #150572 - heathdutton:issue-150174-asyncfn-diagnostic-v2, r=lcnr Improve move error diagnostic for `AsyncFn` closures When an async closure captures a variable by move but is constrained to `AsyncFn` or `AsyncFnMut`, the error message now explains that the closure kind is the issue and points to the trait bound, similar to the existing diagnostic for `Fn`/`FnMut` closures. **Before:** ``` error[E0507]: cannot move out of `foos` which is behind a shared reference --> src/lib.rs:12:20 | 11 | async fn foo(foos: &mut [&mut Foo]) -> Result<(), ()> { | ---- move occurs because `foos` has type... 12 | in_transaction(async || -> Result<(), ()> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^ `foos` is moved here 13 | for foo in foos { | ---- variable moved due to use in coroutine ``` **After:** ``` error[E0507]: cannot move out of `y`, a captured variable in an `AsyncFn` closure --> src/lib.rs:9:10 | LL | let y = vec![format!("World")]; | - captured outer variable LL | call(async || { | ^^^^^^^^ captured by this `AsyncFn` closure ... help: `AsyncFn` and `AsyncFnMut` closures require captured values to be able to be consumed multiple times, but `AsyncFnOnce` closures may consume them only once --> src/lib.rs:5:27 | LL | fn call<F>(_: F) where F: AsyncFn() {} | ^^^^^^^^^ ``` Fixes #150174
When an async closure captures a variable by move but is constrained to
AsyncFnorAsyncFnMut, the error message now explains that the closure kind is the issue and points to the trait bound, similar to the existing diagnostic forFn/FnMutclosures.Before:
After:
Fixes #150174