Skip to content
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

Fix diagnostics for async block cloning #122589

Merged
merged 2 commits into from
Mar 27, 2024
Merged

Conversation

wutchzone
Copy link
Contributor

Closes #121547

r? diagnostics

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 16, 2024
Comment on lines +471 to +472
capture_kind_span: _,
path_span,
Copy link
Contributor Author

@wutchzone wutchzone Mar 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure what is a more fitting span, whether the path_span or the capture_kind_span. Both seem to be working correctly with the provided test.

Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems fine, but I kind of wish that the message noted that the semantics change due to the clone.

LL | | }.await
| |_________^ value moved here, in previous iteration of loop
|
help: consider cloning the value if the performance cost is acceptable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this error message is not right in spirit. Really we should be saying something like "cloning the value [if this is the behavior that you intended]".

Cloning here could have different semantics than actually moving the value into the async block, for example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to make sure, are you suggesting we should change the help message in general for cloning or only for this particular case in the async block?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't actually know :/ I guess this is a more general problem than what this aims to fix

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May I suggest creating an issue where we can talk about the appropriate wording? I would like to also share my opinion, however, I think this is not the right PR for that.

@bors
Copy link
Contributor

bors commented Mar 18, 2024

☔ The latest upstream changes (presumably #121652) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this work for cases like:

let x = async {
    drop(value);
}.await;
use(value);

Outside of a loop?

@wutchzone
Copy link
Contributor Author

wutchzone commented Mar 19, 2024

FYI: due to the #121652, the suggestion is now (on nightly) even more funnier 😀

error[E0382]: use of moved value: `value`
 --> src/main.rs:3:9
  |
1 |   async fn clone_async_block(value: String) {
  |                              ----- move occurs because `value` has type `String`, which does not implement the `Copy` trait
2 |       for _ in 0..10 {
  |       -------------- inside of this loop
3 | /         async { //~ ERROR: use of moved value: `value` [E0382]
4 | |             drop(value);
  | |                  ----- use occurs due to use in coroutine
5 | |             //~^ HELP: consider cloning the value if the performance cost is acceptable
6 | |         }.await
  | |_________^ value moved here, in previous iteration of loop
  |
help: consider moving the expression out of the loop so it is only moved once
  |
2 ~     let mut value = await;
3 ~     for _ in 0..10 {
4 |         async { //~ ERROR: use of moved value: `value` [E0382]
5 |             drop(value);
6 |             //~^ HELP: consider cloning the value if the performance cost is acceptable
7 ~         }.value
  |

@wutchzone
Copy link
Contributor Author

Does this work for cases like:

let x = async {
   drop(value);
}.await;
use(value);

Outside of a loop?

nightly:

error[E0382]: use of moved value: `value`
 --> src/main.rs:8:13
  |
4 |   async fn clone_async_block(value: String) {
  |                              ----- move occurs because `value` has type `String`, which does not implement the `Copy` trait
5 |       let _x = async {
  |  ______________-
6 | |         drop(value);
  | |              ----- variable moved due to use in coroutine
7 | |     }.await;
  | |_____- value moved here
8 |       consume(value);
  |               ^^^^^ value used here after move
  |
help: consider cloning the value if the performance cost is acceptable
  |
7 |     }.clone().await;
  |      ++++++++

after my patch:

error[E0382]: use of moved value: `value`
 --> src/main.rs:8:13
  |
4 |   async fn clone_async_block(value: String) {
  |                              ----- move occurs because `value` has type `String`, which does not implement the `Copy` trait
5 |       let _x = async {
  |  ______________-
6 | |         drop(value);
  | |              ----- variable moved due to use in coroutine
7 | |     }.await;
  | |_____- value moved here
8 |       consume(value);
  |               ^^^^^ value used here after move
  |
help: consider cloning the value if the performance cost is acceptable
  |
6 |         drop(value.clone());
  |                   ++++++++

I guess it works even for this case.

@bors
Copy link
Contributor

bors commented Mar 23, 2024

☔ The latest upstream changes (presumably #122947) made this pull request unmergeable. Please resolve the merge conflicts.

@compiler-errors
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Mar 26, 2024

📌 Commit 2c433d0 has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 26, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 26, 2024
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#108675 (Document `adt_const_params` feature in Unstable Book)
 - rust-lang#122120 (Suggest associated type bounds on problematic associated equality bounds)
 - rust-lang#122589 (Fix diagnostics for async block cloning)
 - rust-lang#122835 (Require `DerefMut` and `DerefPure` on `deref!()` patterns when appropriate)
 - rust-lang#123049 (In `ConstructCoroutineInClosureShim`, pass receiver by mut ref, not mut pointer)
 - rust-lang#123055 (enable cargo miri test doctests)
 - rust-lang#123057 (unix fs: Make hurd using explicit new rather than From)
 - rust-lang#123087 (Change `f16` and `f128` clippy stubs to be nonpanicking)
 - rust-lang#123103 (Rename `Inherited` -> `TypeckRootCtxt`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 20770ac into rust-lang:master Mar 27, 2024
11 checks passed
@rustbot rustbot added this to the 1.79.0 milestone Mar 27, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 27, 2024
Rollup merge of rust-lang#122589 - wutchzone:121547, r=compiler-errors

Fix diagnostics for async block cloning

Closes rust-lang#121547

r? diagnostics
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Compiler Suggests Cloning an async Block
4 participants