Tracking Issue for feature(pin_static_ref): Pin::{static_ref,static_mut}

[m-ou-se]

Tracking issue for #![feature(pin_static_ref)], as added by #77726.

Interface:

impl<T: ?Sized> Pin<&'static T> {
    pub const fn static_ref(r: &'static T) -> Pin<&'static T>;
}

impl<T: ?Sized> Pin<&'static mut T> {
    pub const fn static_mut(r: &'static mut T) -> Pin<&'static mut T>;
}

@rustbot modify labels: +B-unstable +C-tracking-issue +T-libs

[Lucretiel]

Sorry for my ignorance, but how is this sound? It seems to trade on the idea that &'static mut can never be moved out of, but I don't see any reason that should be case? Can you not mem::swap a pair of &'static mut T?

EDIT: Thanks for your help everyone, it turned out I had a flawed understanding of how reborrowing works. Cheers

[eddyb]

This has been resolved elsewhere, but effectively you cannot both call Pin::static_mut(r) and use r ever again - that would (roughly) amount to copying r, which would never be allowed for &mut T in general.

It's a bit subtle, but once you create a &'a mut U (or even &'a U) from a &'a mut T, since the 'a is the same in both, they cannot be distinguished at the typesystem level, and so the original has to be considered "perma-borrowed for 'a" (which when 'a = 'static means "forever") to be able to disallow one (the original) and allow the other (the new one), since otherwise the types look the same.

(I would love to have a compiler with one specific borrow exception, to demonstrate what exactly would be broken)

Also, IIRC there was a soundness issue with &'static mut T at some point (largely due to it not being a type you could ever really have values of, pre-Box::leak), but I'm pretty sure it got resolved long ago.

[tmandry]

Can you not mem::swap a pair of &'static mut T?

I had this question as well.. the answer is that you can. But once you put your &'static mut T in a Pin you can never "get it out" again. Nor can you have any other reference to the original value, crucially, since (as @eddyb described) a &'static mut T reference must be the only valid reference to that value.

[RalfJung]

Pin::static_mut is fine, I think

Pin::static_ref, on the other hand, I think is potentially problematic. You can think of pinning as a "typestate", and the type can have its own separate custom invariants for the "pinned" and "unpinned" typestates. The Pin::static_ref function may assume that &'static T points to something that satisfies the "unpinned" typestate invariant, and has to now prove that it also satisfies the "pinned" typestate invariant. I don't see any way to justify this. I haven't constructed a counterexample yet, either, but I would tread very carefully around this method.

[m-ou-se]

Hm, interesting. Pin::static_ref was the one I needed. I only added Pin::static_mut for completeness.

Use case (e.g. in the standard library):

static MUTEX: MutexThatGetsVeryAngryIfItIsMoved = ...;

impl MutexThatGetsVeryAngryIfItIsMoved {
    pub fn lock(self: Pin<&Self>) -> ... { ... }
}

fn something() {
    let guard = Pin::static_ref(&MUTEX).lock();
    ...
}

Instead of having all its methods unsafe with the requirement that it hasn't been moved, the methods require Pin<&Self> and can be safe. Pin::static_ref can be used on statics, because the 'static lifetime already promises that the thing won't move.

[RalfJung]

I think this is a (contrived) counterexample, demonstrating that Pin::static_ref is a breaking change:

// Invariant: the integer is 0, except behind shared *unpinned* references it can be whatever.
// There is no `&self` operation so we do not care about those values.
struct Nasty(i32);

impl Nasty {
    pub fn new() -> Self {
        Nasty(0)
    }
    
    pub fn new_shared() -> &'static Self {
        // We seem to violate the invariant here, but there is no operation
        // on `&self` so this is not a problem.
        &Nasty(1)
    }
    
    pub fn check(self: Pin<&Self>) {
        // It would be sound to cause UB for non-0 values here.
        // IOW, this assertion can never fail (for safe callers).
        assert!(self.0 == 0);
    }
}

With Pin::static_ref I can make the assertion fail: Pin::static_ref(Nasty::new_shared()).check().

The example is somewhat similar in spirit to those examples which show that Sync does not imply Send: if there is no operation on &self, the invariant associated with those values can be degenerate.

Of course this is a contrived example, but it does demonstrate that adding Pin::static_ref alters the logical contract associated with pinning.

[m-ou-se]

Is that really a promise that Pin makes though?

https://doc.rust-lang.org/stable/std/pin/struct.Pin.html#safety does not really explicitly state that.

It only says:

A value, once pinned, must remain pinned forever

where pinned is defined a bit above as

pinned, meaning that the data will not be moved or its storage invalidated until it gets dropped

By that definition, the T in a &'static T is pinned, regardless of whether there's a Pin<> wrapper around it.

[RalfJung]

The current docs don't say either way. Being English-language as opposed to formal docs, they don't make sufficiently explicit what exactly the requirement is.

Adding Pin::static_ref imposes a new proof obligation on all unsafe code that defines custom pinning-related invariants for types it exports: if the unpinned shared invariant is satisfied for lifetime 'static, then the pinned shared invariant must be satisfied for lifetime 'static. Nothing in the current docs indicates that this might be a proof obligation unsafe code has to uphold. Hence I argue my example is fine under current Pin.

This would also be the first proof obligation that special-cases the 'static lifetime -- so I don't think I like it. It feels like an ad-hoc hack to me.

(FWIW, I agree that the current docs also don't rule out Pin::static_ref. This situation is known as "independence" in mathematics: the rules as stated do not suffice to confirm or deny the statement. Famously, the axiom of choice is independent from Zermelo–Fraenkel set theory. However, adding a new proof obligation to custom type invariants is a big deal as it affects all code.)