Support Unalign for unsized types?

[joshlf]

Since Unalign<T> is repr(packed), T must be Sized (you can switch to T: ?Sized + Copy, but actually this is still Sized because Copy: Clone and Clone: Sized). We could lift this restriction by wrapping the inner T in a ManuallyDrop. However, we'd need to figure out what to do about dropping. We could implement Drop when T: Sized or when T: Unaligned (so dropping in-place is valid), but when T: !Sized, we'd either have to leak the type or else implement some crazy approximation of dynamic stack allocation in order to move the value into an aligned location in order to drop it in-place. Alternatively, perhaps we can prove that it's never possible to create an owned, unsized Unalign<T>, and so the no-drop thing never matters in practice?

Background: If a type is repr(packed), its fields may live at invalid offsets at runtime, which means that Rust must prevent those fields from being operated on in-place. If a field requires dropping, Rust generates drop glue for these fields by first moving them into the local stack frame with correct alignment. At this point, they can be safely dropped in-place. However, if the type is unsized, then there's no way for it to be moved into the local stack frame. Thus, Rust only allows unaligned fields which don't have drop glue. In the case of generic types, this requires wrapping in a ManuallyDrop.

[joshlf]

cc @djkoloski since you mentioned this behavior in #126 (comment)

[djkoloski]

Requiring T: ?Sized + Copy is the same as requiring T: Sized because Copy: Clone and Clone: Sized.

[joshlf]

Requiring T: ?Sized + Copy is the same as requiring T: Sized because Copy: Clone and Clone: Sized.

Ah hmmm yes that's a very good point.

[joshlf]

Okay, updated to describe our options. Seems like wrapping in a ManuallyDrop might actually work, but there is one big catch relating to dropping unsized values.