Don't mark generators as !Send if a Copy + !Send value is dropped across a yield#99105
Closed
jyn514 wants to merge 1 commit intorust-lang:masterfrom
Closed
Don't mark generators as !Send if a Copy + !Send value is dropped across a yield#99105jyn514 wants to merge 1 commit intorust-lang:masterfrom
!Send if a Copy + !Send value is dropped across a yield#99105jyn514 wants to merge 1 commit intorust-lang:masterfrom
Conversation
jyn514
added
T-compiler
Contributor
|
r? @lcnr (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
Would be worth adding a test for a non-copy but non-dropping type being dropped across a yield, like It should still be fine, though. But I think this would mean going from "this definitely doesn't need drop" to "this might need drop" is a breaking change, whereas bounding it on Copy is fine since removing a copy impl is already a breaking change. |
… across a yield Copy types can neither read nor write their values when dropped (the language guarantees Drop is a no-op). So it doesn't make sense for them to make the generator non-Send.
Member
Author
Oh excellent catch, thank you. I changed it to use I'm not sure how to do this while taking lifetimes into account - |
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Member
Author
|
(the exact way I implemented this seems to not be correct, since it's not picking up items that are copied after a yield - going to wait to fix that until I hear back about whether we want to do this at all) |
lcnr
reviewed
Jul 11, 2022
| impl !Send for S {} | ||
|
|
||
| fn main() { | ||
| println!("{}", std::mem::needs_drop::<S>()); |
Contributor
There was a problem hiding this comment.
Suggested change
| println!("{}", std::mem::needs_drop::<S>()); |
Contributor
It is fine here. Actually considering lifetimes when making decisions based on whether a trait is implemented is pretty difficult (if not impossible in rust). But considering that having any |
tmandry
reviewed
Aug 1, 2022
| ); | ||
|
|
||
| if self.fcx.type_is_copy_modulo_regions(self.fcx.param_env, ty, source_span) { | ||
| // This is only used because it's dropped after the yield. |
Member
Author
|
@tmandry @eholk fyi this code is not correct at all, see #99105 (comment). I suspect getting it to work is going to be kind of tricky. It sounds like you've agreed this is a good idea so I'll try and put in some time to fixing it after RustConf. |
scottmcm
added
the
needs-fcp
Collaborator
|
☔ The latest upstream changes (presumably #101239) made this pull request unmergeable. Please resolve the merge conflicts. |
Contributor
|
Switching to waiting on author. Also S-blocked to signal that it needs an FCP. @rustbot author |
rustbot
added
S-waiting-on-author
apiraino
added
the
S-blocked
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Copy types can neither read nor write their values when dropped (the language guarantees Drop is a no-op).
So it doesn't make sense for them to make the generator non-Send.
Fixes #99104.
This may need a T-lang FCP.
cc @eholk - maybe we want to feature-gate this behind
-Zdrop-tracking? I don't think this is related to building the control-flow-graph, though, it also applies even when we naively assume the value is always dropped at the end of the lexical scope.