`'static` reference to local variable that never goes out of scope?

[joshlf]

Is the following sound? In particular, is it sound to synthesize a 'static reference to a local variable if we can prove that that variable will never go out of scope at runtime because the local scope will never finish executing?

fn with_static<T: 'static, F: FnOnce(&'static T)>(t: T, f: F) {
    let tp: *const T = &t;
    // SAFETY: The `loop {}` below ensures that `t` never goes
    // out of scope.
    let tr: &'static T = unsafe { &*tp };
    f(tr);
    loop {}
    drop(t)
}

[chorman0773]

Lifetimes at the language level don't participate in the operational semantics, they only determines what code is well-formed.

Note that you'll also need to make sure that f doesn't stash the t in a variable and then unwind.

[joshlf]

Ah good point.

[joshlf]

Okay, do you think this is sound?

pub fn with_static<T: 'static, F: FnOnce(&'static mut T)>(t: T, f: F) -> ! {
    struct AbortOnDrop<T>(T);
    impl<T> Drop for AbortOnDrop<T> {
        fn drop(&mut self) {
            loop {}
        }
    }

    let mut t = AbortOnDrop(t);
    let tp: *mut T = &mut t.0;

    // SAFETY: Since we `drop(t)` after the `loop {}`, `t` will only go out of
    // scope if `f` unwinds. If this happens, `AbortOnDrop::drop` will `loop {}`
    // forever before its inner `T` is destructed. Thus, `t.0` will never be
    // destructed, and so it is sound to synthesize a `'static` reference to
    // `t`.
    f(unsafe { &mut *tp });

    loop {}
    drop(t);
}

[Lokathor]

if that drop works like how you seem to think it does, then you don't need to write the loop and drop call after the unsafe function call

[chorman0773]

I wouldn't hold the T value in the guard, since the Drop will invalid any use of .0 (including concurrently).

In any case, from an opsem perspective, as mentioned, it's perfectly fine to "lie" about lifetimes, as long as you don't use the reference after the reference is invalidated (which happens when the storage is deallocated, probably on move, and definitely on a conflicting write). As I mentioned, the lifetimes don't exist at runtime, they're just static guides that make it so that things that aren't valid at runtime aren't valid at compile time.

[joshlf]

I wouldn't hold the T value in the guard, since the Drop will invalid any use of .0 (including concurrently).

Interesting. I was assuming that the invalidation would happen after Drop::drop returned, at which point each field is destructed in turn. Since Drop::drop will never return, I assumed that wouldn't be an issue. Is my understanding incorrect?

[chorman0773]

The move will probably invalidate it.
If you use drop_in_place instead, or the implicit end-of-scope drop, the mutable reference may invalidate the existing reference depending on the precise model

[joshlf]

What guarantees are provided regarding drop order in the presence of unwinding? Is that something I could rely on?

[Lokathor]

I think drops have to be "bottom of the block upwards" regardless of if it's an unwind or a normal return. Otherwise you can trivially make situations that don't make sense.

[RalfJung]

is it sound to synthesize a 'static reference to a local variable if we can prove that that variable will never go out of scope at runtime because the local scope will never finish executing?

Yes. We even have a proof of that in RustBelt. :D You can even take in the t by reference and transmute &'a mut T to &'static mut T.

I would just remove the field from AbortOnDrop to avoid any kind of aliasing issues.

[joshlf]

Note that soundness here may rely on time-traveling UB being impossible (although note that the linked PR is specifically about time-traveling across externally-observable effects, while here we're worried about time-traveling across loop {}s with no such effects).

[RalfJung]

"Time-traveling around loops" is already not a thing. Infinite loops are not an effect and we don't have UB for loop {}, so there's no "after" the loop where there could be UB that could time-travel to "before" the loop.