async/await: improve not-send errors, part 2#65345
Conversation
src/test/ui/async-await/issue-64130-non-send-future-diags.stderr
Outdated
Show resolved
Hide resolved
cba981a to
15ebeab
Compare
This comment has been minimized.
This comment has been minimized.
964759e to
6d16511
Compare
davidtwco
left a comment
There was a problem hiding this comment.
Updated the PR (with help from @nikomatsakis) so that it now applies to more cases.
There was a problem hiding this comment.
This is hack that I wasn't able to find a better solution for.
There was a problem hiding this comment.
What problem is it solving, exactly? I guess that we sometimes capture things "by reference"?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
This diagnostic is misleading.
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I consider this a bit of a bug, also -- it'd be nice if we were more precise around particularly this case)
|
@davidtwco should this still be considered "draft"? |
Probably not, I’ve unmarked it. |
This comment has been minimized.
This comment has been minimized.
473d24e to
6c18dd6
Compare
nikomatsakis
left a comment
There was a problem hiding this comment.
uh I had some comments I apparently never posted :(
There was a problem hiding this comment.
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..?
There was a problem hiding this comment.
but I guess that's pre-existing
There was a problem hiding this comment.
I wonder if we want a helper function for this
There was a problem hiding this comment.
What problem is it solving, exactly? I guess that we sometimes capture things "by reference"?
|
Ping from triage: |
|
Ping from triage, any updates? @nikomatsakis |
|
ping from triage: |
Signed-off-by: David Wood <david@davidtw.co>
This commit corrects the diagnostic note for `async move {}` so that
`await` is mentioned, rather than `yield`.
Signed-off-by: David Wood <david@davidtw.co>
6c18dd6 to
f0b5114
Compare
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.
|
@bors r+ (Tests pass locally) |
|
📌 Commit 5cd9f22 has been approved by |
…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
|
☀️ Test successful - checks-azure |
Part of #64130. Fixes #65667.
This PR improves the errors introduced in #64895 so that they have specialized messages for
SendandSync.r? @nikomatsakis