Skip to content

Commit

Permalink
Rollup merge of rust-lang#81363 - jonhoo:no-unpin-in-pin-future-impl,…
Browse files Browse the repository at this point in the history
… r=m-ou-se

Remove P: Unpin bound on impl Future for Pin

We can safely produce a `Pin<&mut P::Target>` without moving out of the `Pin` by using `Pin::as_mut` directly.

The `Unpin` bound was originally added in rust-lang#56939 following the recommendation of `@withoutboats` in rust-lang#55766 (comment)

That comment does not give explicit justification for why the bound should be added. The relevant context was:

> [ ] Remove `impl<P> Unpin for Pin<P>`
>
> This impl is not justified by our standard justification for unpin impls: there is no pointer direction between `Pin<P>` and `P`. Its usefulness is covered by the impls for pointers themselves.
>
> This futures impl (link to the impl changed in this PR) will need to change to add a `P: Unpin` bound.

The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, as demonstrated by the change requiring no unsafe code and by the existence of `Pin::as_mut`.
  • Loading branch information
JohnTitor authored Jul 28, 2021
2 parents f3fc3f2 + cf40292 commit efa3a2f
Show file tree
Hide file tree
Showing 3 changed files with 41 additions and 2 deletions.
4 changes: 2 additions & 2 deletions library/core/src/future/future.rs
Original file line number Diff line number Diff line change
Expand Up @@ -111,11 +111,11 @@ impl<F: ?Sized + Future + Unpin> Future for &mut F {
#[stable(feature = "futures_api", since = "1.36.0")]
impl<P> Future for Pin<P>
where
P: Unpin + ops::DerefMut<Target: Future>,
P: ops::DerefMut<Target: Future>,
{
type Output = <<P as ops::Deref>::Target as Future>::Output;

fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
Pin::get_mut(self).as_mut().poll(cx)
<P::Target as Future>::poll(self.as_deref_mut(), cx)
}
}
1 change: 1 addition & 0 deletions library/core/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -128,6 +128,7 @@
#![feature(exhaustive_patterns)]
#![feature(no_core)]
#![feature(auto_traits)]
#![feature(pin_deref_mut)]
#![feature(prelude_import)]
#![feature(ptr_metadata)]
#![feature(repr_simd, platform_intrinsics)]
Expand Down
38 changes: 38 additions & 0 deletions library/core/src/pin.rs
Original file line number Diff line number Diff line change
Expand Up @@ -802,6 +802,44 @@ impl<T: ?Sized> Pin<&'static T> {
}
}

impl<'a, P: DerefMut> Pin<&'a mut Pin<P>> {
/// Gets a pinned mutable reference from this nested pinned pointer.
///
/// This is a generic method to go from `Pin<&mut Pin<Pointer<T>>>` to `Pin<&mut T>`. It is
/// safe because the existence of a `Pin<Pointer<T>>` ensures that the pointee, `T`, cannot
/// move in the future, and this method does not enable the pointee to move. "Malicious"
/// implementations of `P::DerefMut` are likewise ruled out by the contract of
/// `Pin::new_unchecked`.
#[unstable(feature = "pin_deref_mut", issue = "86918")]
#[inline(always)]
pub fn as_deref_mut(self) -> Pin<&'a mut P::Target> {
// SAFETY: What we're asserting here is that going from
//
// Pin<&mut Pin<P>>
//
// to
//
// Pin<&mut P::Target>
//
// is safe.
//
// We need to ensure that two things hold for that to be the case:
//
// 1) Once we give out a `Pin<&mut P::Target>`, an `&mut P::Target` will not be given out.
// 2) By giving out a `Pin<&mut P::Target>`, we do not risk of violating `Pin<&mut Pin<P>>`
//
// The existence of `Pin<P>` is sufficient to guarantee #1: since we already have a
// `Pin<P>`, it must already uphold the pinning guarantees, which must mean that
// `Pin<&mut P::Target>` does as well, since `Pin::as_mut` is safe. We do not have to rely
// on the fact that P is _also_ pinned.
//
// For #2, we need to ensure that code given a `Pin<&mut P::Target>` cannot cause the
// `Pin<P>` to move? That is not possible, since `Pin<&mut P::Target>` no longer retains
// any access to the `P` itself, much less the `Pin<P>`.
unsafe { self.get_unchecked_mut() }.as_mut()
}
}

impl<T: ?Sized> Pin<&'static mut T> {
/// Get a pinned mutable reference from a static mutable reference.
///
Expand Down

0 comments on commit efa3a2f

Please sign in to comment.