The pin documentation states that "for pinned data you have to maintain the invariant that its memory will not get invalidated or repurposed from the moment it gets pinned until when drop is called".
In this playground, I leak a pinned data and make it invalid by dropping something it references. All without unsafe code. Doesn't this violate the drop guarantee?
(I understand that in the playground the pinned data is not safely reachable anymore. Still, if we use unsafe code that relies on the drop guarantee there could be problems.)
It's an interesting point, but the drop guarantee must necessarily allow this. Thus, any unsafe code relying on the drop guarantee must be careful to not let this type of situation cause UB.
By must necessarily allow this do you mean it is a language level thing? Does this mean it is unsound to rely on the drop guarantee for all non-'static types?
The lingered memory is valid. Schrödinger's cat is always alive in the box. You just can't open the box.
It is unsafe to add a mobile phone inside the box. If you do be sure everyone loses the number before s is dropped. Knowing the number is invalid after.
By necessarily I mean that since your code is safe, the pin guarantee must allow your code.
Regarding non-static types, well, if the non-static type has a pinned field which is static, then that field remains valid and non-problematic to access, even if the full struct has some problems.
The key word here is "its memory". By dropping s you didn't invalidate the memory of the pinned data, you only invalidated something it did have a reference to.