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

Suggest move for closures and async blocks in more cases. #70906

Merged
merged 1 commit into from
Apr 9, 2020

Conversation

gizmondo
Copy link
Contributor

@gizmondo gizmondo commented Apr 7, 2020

Fixes #66107, also improves #67577
Related PR #65166

@rust-highfive
Copy link
Collaborator

r? @ecstatic-morse

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 7, 2020
@gizmondo
Copy link
Contributor Author

gizmondo commented Apr 7, 2020

r? @estebank

@@ -1225,8 +1204,9 @@ impl<'cx, 'tcx> MirBorrowckCtxt<'cx, 'tcx> {
);

let msg = match category {
ConstraintCategory::Return => "closure is returned here".to_string(),
ConstraintCategory::OpaqueType => "generator is returned here".to_string(),
ConstraintCategory::Return | ConstraintCategory::OpaqueType => {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I feel the existing behavior is wrong, users of async should not see generator in error messages.
But not sure what wording should be used instead.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think that we'll 1) need to be able to differentiate between closures and generators here in the first place and 2) in the OpaqueType it should be "async closure is returned here", right?

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed that saying generators in an error message is basically never right, regardless.

Comment on lines +763 to +768
category:
category
@
(ConstraintCategory::Return
| ConstraintCategory::CallArgument
| ConstraintCategory::OpaqueType),
Copy link
Contributor

@Centril Centril Apr 7, 2020

Choose a reason for hiding this comment

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

Highlighting this for a rustfmt issue (rust-lang/rustfmt#4110) I'm filing (no need to do anything about it in this PR).

Comment on lines 20 to 37
error[E0373]: closure may outlive the current function, but it borrows `x`, which is owned by the current function
--> $DIR/async-borrowck-escaping-block-error.rs:11:11
|
LL | async { *x }
| ^^^-^^
| | |
| | `x` is borrowed here
| may outlive borrowed value `x`
|
note: closure is returned here
--> $DIR/async-borrowck-escaping-block-error.rs:11:5
|
LL | async { *x }
| ^^^^^^^^^^^^
help: to force the async block to take ownership of `x` (and any other referenced variables), use the `move` keyword
|
LL | async move { *x }
| ^^^^^^^^^^^
Copy link
Contributor

Choose a reason for hiding this comment

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

Actually, I think the output here should talk about closures, it should talk about async blocks instead (same in the previously existing test):


error[E0373]: async block may outlive the current function, but it borrows `x`, which is owned by the current function
  --> $DIR/async-borrowck-escaping-block-error.rs:11:11
   |
LL |     async { *x }
   |           ^^^-^^
   |           |  |
   |           |  `x` is borrowed here
   |           may outlive borrowed value `x`
   |
note: async block is returned here
  --> $DIR/async-borrowck-escaping-block-error.rs:11:5
   |
LL |     async { *x }
   |     ^^^^^^^^^^^^
help: to force the async block to take ownership of `x` (and any other referenced variables), use the `move` keyword
   |
LL |     async move { *x }
   |           ^^^^^^^^^^^

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated, thanks.

@estebank
Copy link
Contributor

estebank commented Apr 8, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Apr 8, 2020

📌 Commit aaebbe1 has been approved by estebank

@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 Apr 8, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 9, 2020
Rollup of 7 pull requests

Successful merges:

 - rust-lang#70134 (add basic support of OsStrExt for HermitCore)
 - rust-lang#70565 (Add inline attributes for functions used in the query system)
 - rust-lang#70828 (rustdoc: Don't try to load source files from external crates)
 - rust-lang#70870 (Fix abuses of tykind::err)
 - rust-lang#70906 (Suggest move for closures and async blocks in more cases.)
 - rust-lang#70912 (Do not suggest adding type param when `use` is already suggested)
 - rust-lang#70930 (add tracking issue to `VecDeque::make_contiguous`)

Failed merges:

r? @ghost
@bors bors merged commit 6f8fc4d into rust-lang:master Apr 9, 2020
@gizmondo gizmondo deleted the 66107 branch April 9, 2020 06:32
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

async-block diagnostics do not suggest async move when it may be needed
7 participants