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

async/await: improve not-send errors, part 2 #65345

Merged

Conversation

davidtwco
Copy link
Member

@davidtwco davidtwco commented Oct 12, 2019

Part of #64130. Fixes #65667.

This PR improves the errors introduced in #64895 so that they have specialized messages for Send and Sync.

r? @nikomatsakis

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 12, 2019
src/libcore/marker.rs Outdated Show resolved Hide resolved
@rust-highfive

This comment has been minimized.

@davidtwco davidtwco force-pushed the issue-64130-async-send-sync-error-improvements branch from 964759e to 6d16511 Compare October 30, 2019 17:10
Copy link
Member Author

@davidtwco davidtwco left a comment

Choose a reason for hiding this comment

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

Updated the PR (with help from @nikomatsakis) so that it now applies to more cases.

let ty = ty.builtin_deref(false).map(|ty_and_mut| ty_and_mut.ty).unwrap_or(ty);
let target_ty = target_ty.builtin_deref(false)
.map(|ty_and_mut| ty_and_mut.ty)
.unwrap_or(target_ty);
Copy link
Member Author

Choose a reason for hiding this comment

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

This is hack that I wasn't able to find a better solution for.

Copy link
Contributor

Choose a reason for hiding this comment

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

What problem is it solving, exactly? I guess that we sometimes capture things "by reference"?

Copy link
Member Author

@davidtwco davidtwco Nov 8, 2019

Choose a reason for hiding this comment

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

I wasn’t able to find a way to check for equality of types that were ty::Ref, nothing seemed to work. There are some messages in the Zulip thread detailing what I tried when I was last looking at this. Nope, misremembered.

LL | fut().await;
| ^^^^^^^^^^^ await occurs here, with `x` maybe used later
LL | }
| - `x` is later dropped here
Copy link
Member Author

Choose a reason for hiding this comment

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

This diagnostic is misleading.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, because of the drop(x) that comes before? I suppose that's true, though it'd ordinarily be quite helpful. Perhaps we can just weaken the language to "x may be dropped here"?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I think we could adjust the wording to better explain why the drop call isn’t enough to avoid the type being held over the await point.

Copy link
Contributor

Choose a reason for hiding this comment

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

I consider this a bit of a bug, also -- it'd be nice if we were more precise around particularly this case)

@nikomatsakis
Copy link
Contributor

@davidtwco should this still be considered "draft"?

@davidtwco davidtwco marked this pull request as ready for review October 30, 2019 18:34
@davidtwco
Copy link
Member Author

@davidtwco should this still be considered "draft"?

Probably not, I’ve unmarked it.

@bors

This comment has been minimized.

@davidtwco davidtwco force-pushed the issue-64130-async-send-sync-error-improvements branch from 473d24e to 6c18dd6 Compare November 8, 2019 21:10
Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

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

uh I had some comments I apparently never posted :(

src/librustc/traits/error_reporting.rs Show resolved Hide resolved
};

// Look at the last interior type to get a span for the `.await`.
let await_span = tables.generator_interior_types.iter().map(|i| i.span).last().unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

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

huh, so we just take the last span from the table? seems a bit arbitrary. Ideally, it would be tied to the value we are citing..?

Copy link
Contributor

Choose a reason for hiding this comment

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

but I guess that's pre-existing


// Get the tables from the infcx if the generator is the function we are
// currently type-checking; otherwise, get them by performing a query.
// This is needed to avoid cycles.
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we want a helper function for this

let ty = ty.builtin_deref(false).map(|ty_and_mut| ty_and_mut.ty).unwrap_or(ty);
let target_ty = target_ty.builtin_deref(false)
.map(|ty_and_mut| ty_and_mut.ty)
.unwrap_or(target_ty);
Copy link
Contributor

Choose a reason for hiding this comment

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

What problem is it solving, exactly? I guess that we sometimes capture things "by reference"?

@JohnCSimon JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 16, 2019
@JohnCSimon
Copy link
Member

Ping from triage:
@davidtwco Can you please address the comments from @nikomatsakis ? Thank you!
cc: @Centril

@davidtwco
Copy link
Member Author

@davidtwco davidtwco added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 16, 2019
@Alexendoo
Copy link
Member

Ping from triage, any updates? @nikomatsakis

@JohnCSimon JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 7, 2019
@JohnCSimon
Copy link
Member

ping from triage:
@davidtwco - can you please address the merge conflict?
once that happens...
@nikomatsakis - please review this PR

This commit corrects the diagnostic note for `async move {}` so that
`await` is mentioned, rather than `yield`.

Signed-off-by: David Wood <[email protected]>
The reason we were invoking `builtin_deref` was to enable comparisons
when the type was `&T`. For the reasons outlined in the comment, those
comparisons failed because the regions disagreed.
@nikomatsakis
Copy link
Contributor

@bors r+

(Tests pass locally)

@bors
Copy link
Contributor

bors commented Dec 11, 2019

📌 Commit 5cd9f22 has been approved by nikomatsakis

@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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 11, 2019
@bors
Copy link
Contributor

bors commented Dec 11, 2019

⌛ Testing commit 5cd9f22 with merge 27d6f55...

bors added a commit that referenced this pull request Dec 11, 2019
…provements, r=nikomatsakis

async/await: improve not-send errors, part 2

Part of #64130. Fixes #65667.

This PR improves the errors introduced in #64895 so that they have specialized messages for `Send` and `Sync`.

r? @nikomatsakis
@bors
Copy link
Contributor

bors commented Dec 11, 2019

☀️ Test successful - checks-azure
Approved by: nikomatsakis
Pushing 27d6f55 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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/Await: Confusing error message when using non-Send type in async fn
8 participants