Unaligned Fields Support

[BennoLossin]

Structs with unaligned fields (through the repr(packed) attribute) were allowed before db96c51, which is unsound. After that commit, they stopped working, because initialized fields accessors create references to those fields; the compiler rejects creating references to unaligned fields. We then added explicit support for packed structs in 71988db by providing a way to not emit these field accessors. This is unsound, since the entire architecture of pin-init relies on aligned pointers. We thus removed the support again in #111.

To support packed structs there are two possibilities:

1. Extend the current trait infrastructure with new ones:

• Add new traits Unaligned[Pin]Init that relax the alignment requirement of their pointer
• Add an attribute to init! to make it emit such an initializer instead (taking care of field accessors, only using ptr::write_unaligned and also expecting unaligned initializers)

2. Extend the current [Pin]Init traits:

• Extend the Init trait with an associated boolean constant that specifies if the pointer must be aligned or not
• Make the init! macro propagate this constant & ensure correct behavior based on it

Both of these seem quite invasive. So I'd like to wait and see for a real use-case of packed structs with pin-init that cannot easily work around it.

[jannau]

The use cases in Asahi Linux rust drivers are rewritten to avoid using #[repr(C, packed)]. In a few cases it was necessary to use unaligned integer types like:

#[derive(Copy, Clone, Default)]
#[repr(C, packed(1))]
pub struct U64(pub(crate) u64);

impl fmt::Debug for U64 { ... }

There other cases like #[derive(Debug)] and atomics which preclude using packed larger structures.

Now that the use cases in the Asahi Linux drivers are worked around there is no need to support unaligned fields in pin-init.