From a0e0849a3b1710139d84be846a444c12297cfd2b Mon Sep 17 00:00:00 2001 From: Wim Looman Date: Sun, 21 Apr 2019 13:27:36 +0200 Subject: [PATCH] Add Pin::{into_inner,into_inner_unchecked} --- src/libcore/pin.rs | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/src/libcore/pin.rs b/src/libcore/pin.rs index dbf3dcf03a3c0..e74ed9b7889cb 100644 --- a/src/libcore/pin.rs +++ b/src/libcore/pin.rs @@ -349,6 +349,18 @@ where // around pinning. unsafe { Pin::new_unchecked(pointer) } } + + /// Unwraps this `Pin

` returning the underlying pointer. + /// + /// This requires that the data inside this `Pin` is [`Unpin`] so that we + /// can ignore the pinning invariants when unwrapping it. + /// + /// [`Unpin`]: ../../std/marker/trait.Unpin.html + #[unstable(feature = "pin_into_inner", issue = "60245")] + #[inline(always)] + pub fn into_inner(pin: Pin

) -> P { + pin.pointer + } } impl Pin

{ @@ -434,6 +446,28 @@ impl Pin

{ pub fn as_ref(self: &Pin

) -> Pin<&P::Target> { unsafe { Pin::new_unchecked(&*self.pointer) } } + + /// Unwraps this `Pin

` returning the underlying pointer. + /// + /// # Safety + /// + /// This function is unsafe. You must guarantee that you will continue to + /// treat the pointer `P` as pinned after you call this function, so that + /// the invariants on the `Pin` type can be upheld. If the code using the + /// resulting `P` does not continue to maintain the pinning invariants that + /// is a violation of the API contract and may lead to undefined behavior in + /// later (safe) operations. + /// + /// If the underlying data is [`Unpin`], [`Pin::into_inner`] should be used + /// instead. + /// + /// [`Unpin`]: ../../std/marker/trait.Unpin.html + /// [`Pin::into_inner`]: #method.into_inner + #[unstable(feature = "pin_into_inner", issue = "60245")] + #[inline(always)] + pub unsafe fn into_inner_unchecked(pin: Pin

) -> P { + pin.pointer + } } impl Pin

{