Require allocator to be static for boxed Pin-API

[TimDiekmann]

Allocators has to retain their validity until the instance and all of its clones are dropped. When pinning a value, it must live forever, thus, the allocator requires a 'static lifetime for pinning a value. Example from reddit:

let alloc = MyAlloc(/* ... */);
let pinned = Box::pin_in(42, alloc);
mem::forget(pinned); // Now `value` must live forever
// Otherwise `Pin`'s invariants are violated, storage invalidated
// before Drop was called.
// borrow of `memory` can end here, there is no value keeping it.
drop(alloc); // Oh, value doesn't live forever.

[rust-highfive]

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

[DutchGhost]

Does this requirement also need to be on into_pin (https://github.com/rust-lang/rust/blob/master/library/alloc/src/boxed.rs#L805) ? And perhaps other places as well?

[Mark-Simulacrum]

cc @withoutboats

[TimDiekmann]

Does this requirement also need to be on into_pin (https://github.com/rust-lang/rust/blob/master/library/alloc/src/boxed.rs#L805) ? And perhaps other places as well?

Good point, I added the bound to some other places.

---

cc @withoutboats

Do you want me reassign this PR to @withoutboats?

[Mark-Simulacrum]

No, I can review, just wanted to ping.

[Mark-Simulacrum]

r=me with commits squashed.

I tried to do a cursory check for other cases where this would be needed and didn't find anything, though it's no guarantee. It's a bit concerning that these bounds are necessary, in some sense, but I think we just need to be careful -- ultimately no old code should break. Maybe something to note on API guidelines or similar?

[TimDiekmann]

@Mark-Simulacrum

r=me with commits squashed.

Done, but I don't have the permissions to r+ unless you delegate+.

---

It's a bit concerning that these bounds are necessary, in some sense, but I think we just need to be careful

I'm not 100% sure neither, if all of them are necessary, but I agree, that staying conservative is the way to go here. Dropping the bound later is no problem.

---

ultimately no old code should break

This won't be the case as it only affects the allocator-parameter and that is unstable.

---

Maybe something to note on API guidelines or similar?

Hmm, what do you mean? Regarding the pin-API in general?

[Mark-Simulacrum]

Yes, as we add allocator parameters, it can be easy to think that it'll always be 'static. Noting somewhere that this is not true explicitly I think would be good. Not directly related to Pin, though.

@bors r+

[bors]

📌 Commit 7387f48 has been approved by Mark-Simulacrum

[TimDiekmann]

I'll add a note to the AllocRef documentation. Thanks for the review!

[withoutboats]

I feel a bit concerned about this, as Pin was certainly not designed with custom allocators in mind. We should be very careful about how we move here and make sure we have more formal consideration of the safety requirements of allocators before stabilization.

The most conservative option would be to get rid of pin_in and have all the other Pin APIs only implemented for Box<T, Global>. Not calling for that, but we should keep pinning as an unresolved question for stabilization and possibly fall back to that.