Re: [PATCH 2/2] rust: pin-init: internal: init: document load-bearing fact of field accessors

[Benno Lossin]

On Sat Feb 28, 2026 at 12:55 PM CET, Gary Guo wrote:
> On Sat Feb 28, 2026 at 11:37 AM GMT, Benno Lossin wrote:
>> diff --git a/rust/pin-init/internal/src/init.rs b/rust/pin-init/internal/src/init.rs
>> index da53adc44ecf..533029d53d30 100644
>> --- a/rust/pin-init/internal/src/init.rs
>> +++ b/rust/pin-init/internal/src/init.rs
>> @@ -251,6 +251,11 @@ fn init_fields(
>>                  });
>>                  // Again span for better diagnostics
>>                  let write = quote_spanned!(ident.span()=> ::core::ptr::write);
>> +                // NOTE: the field accessor ensures that the initialized struct is not
>> +                // `repr(packed)`. If it were, the compiler would emit E0793. We do not support
>> +                // packed structs, since `Init::__init` requires an aligned pointer; the same
>> +                // requirement that the call to `ptr::write` below has.
>> +                // For more info see <https://github.com/Rust-for-Linux/pin-init/issues/112>
>
> The emphasis should be unaligned fields instead of `repr(packed)`. Of course,
> unaligned fields can only occur with `repr(packed)`, but packed structs can
> contain well-aligned fields, too (e.g. 1-byte aligned members, or
> `repr(packed(2))` with 2-byte aligned members, etc...). Rust permits creation of
> references to these fields.

Yeah that's a more accurate account of things.

> Something like:
>
>     NOTE: the field accessor ensures that the initialized field is properly
>     aligned. Unaligned fields will cause the compiler to emit E0793. We do not
>     support unaligned fields since `Init::__init` requires an aligned pointer;
>     the `ptr::write` below has the same requirement.

That's a much better suggestion, I'll send an updated series later
today.

> Also, it is not immediately clear to me which one, buyt one of the two occurance
> should be `PinInit::__pin_init`?

No, `PinInit::__pin_init` is never called from the macro, since that
only makes sense for structurally pinned fields. That info isn't
available at the callsite of `init!`. We emit it in `#[pin_data]` which
exposes it to `init!` via the `PinData`. That ZST has a method with the
same name as the field and it takes the respective initializer (so `impl
Init` or `impl PinInit`) and just runs said initializer.

This happens in the second hunk in the case where `pinned == true`.

Cheers,
Benno