poll_fn and Unpin: fix pinning #156
Conversation
Keeping this crate's poll_fn in sync with that of rust's
library/core/src/future/poll_fn.rs.
Their merge provides all the details.
rust-lang/rust#102737
None of this crate's uses of poll_fn are affected. It protects against
misuse in the future which could have led to UB as the above mentioned
PR points out with an example of a double free becoming possible.
|
@Noah-Kennedy Please check that my changes look the ones introduced with that PR referenced because I did them by hand. I didn't pull the git commit and apply it to this file. |
|
Thinking about this now, do we even need our own |
|
Does that mean tokio-uring MSRV becomes 1.64.0? |
|
We don't really have an MSRV policy for tokio-uring. |
|
So far, this crate has been piggy backing off tokio. And tokio has an MSRV that goes back six months. We could merge this with a note saying it should be removed when 1.64.0 becomes the tokio MSRV. So we continue to track tokio. |
|
I'm not entirely sure which older Rust versions we work on currently. We may not even work on tokio's oldest supported version, and I don't see any reason that we should maintain an MSRV at this point. |
|
By not maintaining an MSRV, you mean you think it's okay to require current be used by anyone wanting to use this crate? Then the README should probably say that. But I could be in above my head here. You can make these changes without noise from me. You've been at this successfully a long time. No hard feelings if you let this PR wither and then get closed. |
|
My view: this crate is marked as both experimental and likely to changed. We should not even be attempting to keep a MSRV in tokio or rustc. |
|
I would just like there to be a better reason someone had to use the 1.64.0 compiler. For this, it seems easy to not change what we were doing. |
|
It could always be punted to an issue |
|
@Noah-Kennedy what should we do with this? I think it safer to just merge the changes and remove the code at a later time. But the other way is okay too. |
|
Let's close this and just get rid of our version of this method. |
|
Obsoleted given merge of #194 |
Keeping this crate's poll_fn in sync with that of rust's library/core/src/future/poll_fn.rs.
Their merge provides all the details.
None of this crate's uses of poll_fn are affected. It protects against misuse in the future which could have led to UB as the above mentioned PR points out with an example of a double free becoming possible.