-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Use pinning for generators to make trait safe #55704
Conversation
r? @dtolnay (rust_highfive has picked a reviewer for you, use r? to override) |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
- error[E0277]: the trait bound `[static generator@$DIR/static-not-unpin.rs:19:25: 21:6 _]: std::marker::Unpin` is not satisfied
+ error[E0277]: the trait bound `[static generator@$DIR/static-not-unpin.rs:19:25: 21:6 _]: std::pin::Unpin` is not satisfied It definitely mentions |
And testing on an |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
So, that caused my new test case to pass, but broke a lot of other cases that relied on the previous ordering. I would have thought that the default ordering would be by declaration order, but I don't know how that could be different between my machines and travis'. |
ded732d
to
dea099a
Compare
So this is basically what we always meant to do, just at the time Zoxc implemented the previous iteration of the generator API, std API changes look good. 👍 @bors r? @eddyb can you review the compiler changes here and also confirm that the generator transform doesn't need to be changed with this PR |
The generator transform should use cc @Zoxc |
I think I can see how to update the transform. At a guess it currently works because the output MIR is self-consistent with what type it thinks the generator argument is, and the type it thinks the argument is is layout compatible with the actual type passed in. There must not be any validation of the signature after the transform happens. |
I suggesting replacing |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
I think I have to also update the debug-info generation: rust/src/librustc_codegen_llvm/mir/mod.rs Lines 593 to 598 in ddd4b19
I have a patch to do that, but I still have to figure out how to test it. There appear to be some debuginfo tests, but nothing covering generators, and when I run the existing tests I get
EDIT: Found the gdb issue, need to sign it for macOS, guess I just need to look into how to write the test for it now. |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
// option. This file may not be copied, modified, or distributed | ||
// except according to those terms. | ||
|
||
// normalize-stderr-test "std::pin::Unpin" -> "std::marker::Unpin" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not been able to figure out why travis shows a different path for this compared to the two machines with rustc I've been able to test on. I attempted to trace through where the diagnostics get the path from, and as far as I can tell everything should be deterministic. The path chosen appears to come from the visible_parent_map
built here, this is done as a BFS, and should be deterministic within a single crate. Following the order of an items children back from here through the different representations all the way to libsyntax
there doesn't appear to be anything that should change the order, then in libsyntax
an items children come out in parse order. std
re-exports the core::marker
module before the core::pin
module, so the path chosen to be displayed should be std::marker::Pin
.
Parse/declaration order is also consistent with the failures in https://travis-ci.org/rust-lang/rust/jobs/451369080, that test commit forced the child order while constructing visible_parent_map
to be sorted by name. All the failures were swapping paths that were declared earlier with paths declared later but alphabetically sorted earlier.
This will also become moot soon as #55766 is proposing to remove the std::pin::Unpin
re-export (although, it does plan to add it to the prelude which will then become the preferred path).
Travis appears to have found all the test cases I didn't... Other than the comment I just left this is complete as far as I'm aware. I'd prefer to land this with that workaround and I'll open an issue about the non-deterministic diagnostics. Let me know whether there's anything else and I can squash all the fixups in. |
☔ The latest upstream changes (presumably #57765) made this pull request unmergeable. Please resolve the merge conflicts. |
827e794
to
a21c95f
Compare
Pushed an untested rebase, there were only trivial import conflicts in the |
@bors r+ |
📌 Commit a21c95f has been approved by |
Use pinning for generators to make trait safe I'm unsure whether there needs to be any changes to the actual generator transform. Tests are passing so the fact that `Pin<&mut T>` is fundamentally the same as `&mut T` seems to allow it to still work, but maybe there's something subtle here that could go wrong. This is specified in [RFC 2349 § Immovable generators](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md#immovable-generators) (although, since that RFC it has become safe to create an immovable generator, and instead it's unsafe to resume any generator; with these changes both are now safe and instead the unsafety is moved to creating a `Pin<&mut [static generator]>` which there are safe APIs for). CC #43122
☀️ Test successful - checks-travis, status-appveyor |
Can I ask a question? previously, i was storing a generator using this way:
But after this change, how can I store a generator in a struct? |
which you can get from |
@Arnavion wow.. thank you very much!! |
As a side note, to then poll it you can use |
Generators now use `Pin` to make `resume` safe: rust-lang/rust#55704
I'm unsure whether there needs to be any changes to the actual generator transform. Tests are passing so the fact that
Pin<&mut T>
is fundamentally the same as&mut T
seems to allow it to still work, but maybe there's something subtle here that could go wrong.This is specified in RFC 2349 § Immovable generators (although, since that RFC it has become safe to create an immovable generator, and instead it's unsafe to resume any generator; with these changes both are now safe and instead the unsafety is moved to creating a
Pin<&mut [static generator]>
which there are safe APIs for).CC #43122