rust: pin_init: internal: use `loop {}` to produce never value

In the `init!`/`pin_init!` macros, we rely on a trick that assigns never
(`!`) values to all mentioned fields in never-executed code to

rust: pin_init: internal: use `loop {}` to produce never value

In the `init!`/`pin_init!` macros, we rely on a trick that assigns never
(`!`) values to all mentioned fields in never-executed code to let the
compiler check that all fields have been initialized.

Currently we use `::core::panic!()` to produce this value, but before Rust
1.91.0, it creates outlined `panic_cold_explicit` functions which do not
get removed by the optimizer, thus leaving dead code behind in the binary.
This has been fixed by [1], which lands in Rust 1.91.0+, higher than the
kernel minimum version 1.85.0.

This causes ~200 dead `panic_cold_explicit` instances being included in the
binary, with ~90 of them from nova-core's usage of pin-init.

Work around the issue by using `loop {}` which creates the never value
without macro expansion or function call at all. All instances of
`panic_cold_explicit` outside libcore are removed by this change in my
kernel build.

Link: https://github.com/rust-lang/rust/pull/145304 [1]
Link: https://patch.msgid.link/20260508152950.833635-1-gary@kernel.org
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: remove `E` from `InitClosure`

Move `E` from type to trait impl block. This greatly shortens the
monomorphized type names. The `__pinned_init` function name is only
slightly shortened

rust: pin-init: remove `E` from `InitClosure`

Move `E` from type to trait impl block. This greatly shortens the
monomorphized type names. The `__pinned_init` function name is only
slightly shortened as it still encodes the `E` as part of `PinInit<T, E>`
in the symbol.

`T` cannot be moved to trait impl block otherwise it will start to conflict
with the `impl Init<T> for T` as Rust cannot deduce that there're no types
that fulfill `T: FnOnce(*mut T)`.

Link: https://patch.msgid.link/20260527-pin-init-sync-v1-6-e20335ed2501@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: move `InitClosure` out from `__internal`

The `__internal` module is for exposing internal items publicly to
procedural macros (pin-init-internal). Types that are crate-local only can

rust: pin-init: move `InitClosure` out from `__internal`

The `__internal` module is for exposing internal items publicly to
procedural macros (pin-init-internal). Types that are crate-local only can
just have proper visibility and does not need to be in `__internal`.

The type name of `InitClosure` can often shows up in symbol names, this
reduces the length slightly.

Link: https://patch.msgid.link/20260527-pin-init-sync-v1-5-e20335ed2501@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: docs: fix typos in MaybeZeroable documentation

Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Link: https://patch.msgid.link/20260527-pin-init-sync-v1-4-e20335ed2501@garyguo.net
Sig

rust: pin-init: docs: fix typos in MaybeZeroable documentation

Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Link: https://patch.msgid.link/20260527-pin-init-sync-v1-4-e20335ed2501@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: suppress `non_snake_case` lint in `[pin_]init!`

Allows `non_snake_case` lint on local variables generated in `[pin_]init!`.

Conceptually the identifiers in `[pin_]init!` j

rust: pin-init: internal: suppress `non_snake_case` lint in `[pin_]init!`

Allows `non_snake_case` lint on local variables generated in `[pin_]init!`.

Conceptually the identifiers in `[pin_]init!` just references the field
names, and are not defining them, so the warning should not be generated,
similar to how constructing a struct with non-snake-case field names do no
generate these warnings.

Reported-by: Gary Guo <gary@garyguo.net>
Closes: https://github.com/Rust-for-Linux/pin-init/issues/125
Closes: https://lore.kernel.org/rust-for-linux/DGTBJBIVFZ2K.2F1ZEFGY0G7NK@garyguo.net/
Fixes: 42415d163e5d ("rust: pin-init: add references to previously initialized fields")
Signed-off-by: Mirko Adzic <adzicmirko97@gmail.com>
[ Reworded commit message - Gary ]
Link: https://patch.msgid.link/20260527-pin-init-sync-v1-3-e20335ed2501@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: suppress `non_snake_case` lint in `#[pin_data]`

Allows `non_snake_case` lint on struct fields generated by `#[pin_data]`.

Since the same warning will be reported by the co

rust: pin-init: internal: suppress `non_snake_case` lint in `#[pin_data]`

Allows `non_snake_case` lint on struct fields generated by `#[pin_data]`.

Since the same warning will be reported by the compiler on the struct
definition, having extra warnings for the generated code is unnecessary
and confusing.

Signed-off-by: Mirko Adzic <adzicmirko97@gmail.com>
Link: https://patch.msgid.link/20260527-pin-init-sync-v1-2-e20335ed2501@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: pin_data: filter non-`#[cfg]` attr in generated code

When using a macro with custom attributes in a `#[pin_data]` struct it
can mess up the generated code. The generated co

rust: pin-init: internal: pin_data: filter non-`#[cfg]` attr in generated code

When using a macro with custom attributes in a `#[pin_data]` struct it
can mess up the generated code. The generated code needs nothing more than
the `#[cfg]` attribute, thus strip away all other attributes.

[ Rebased and updated to only include `#[cfg]` instead of both `#[cfg]` and
`#[doc]`; doc is not needed for the generated hidden items. - Gary ]

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Co-developed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260527-pin-init-sync-v1-1-e20335ed2501@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: project using full slot

Instead of projecting using pointer to a field project the full slot. This
further shifts the code generation from the initializer site to the struc

rust: pin-init: internal: project using full slot

Instead of projecting using pointer to a field project the full slot. This
further shifts the code generation from the initializer site to the struct
definition site, which means less code is generated overall.

It also makes the safety comment easier to justify, as now the projection
is done by the `#[pin_data]` macro which has full visibility of pinnedness
of fields.

The field alignment could also be checked on the `#[pin_data]` side;
however, since `init!()` macro works for other type of structs, we cannot
remove the alignment check from `init!`/`pin_init!` side anyway, so I opted
to still keep the alignment check in init.rs.

Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: project slots instead of references

By projecting slots, the `pin_init!` and `init!` code path can be more
unified. This also reduces the amount of macro-generated code and

rust: pin-init: internal: project slots instead of references

By projecting slots, the `pin_init!` and `init!` code path can be more
unified. This also reduces the amount of macro-generated code and shifts
them to the shared infrastructure.

Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: make `make_closure` inherent methods

The `InitData` and `PinData` traits do not need to exist, the inference
helpers could be inherent methods instead.

There is no risk fo

rust: pin-init: internal: make `make_closure` inherent methods

The `InitData` and `PinData` traits do not need to exist, the inference
helpers could be inherent methods instead.

There is no risk for calling the wrong methods even when user defines it,
as inherent methods take priority over trait methods.

With this change, it unlocks the possibility of attaching additional bounds
to the method per type, which is not possible for trait methods.

Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: use marker on drop guard type for pinned fields

Instead of projecting the created reference, simply create drop guards with
different marker types and have the `let_binding

rust: pin-init: internal: use marker on drop guard type for pinned fields

Instead of projecting the created reference, simply create drop guards with
different marker types and have the `let_binding()` method of guards of
different marker produce different type instead.

This allows more flexible lifetime as this is now controlled by the guard.
This will be needed when implementing self-referential fields.

Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: init: handle code blocks early

`InitializerKind::Code` is a special case where it does not initialize a
field, and thus generate no guard and accessors. Handle it earlier a

rust: pin-init: internal: init: handle code blocks early

`InitializerKind::Code` is a special case where it does not initialize a
field, and thus generate no guard and accessors. Handle it earlier and make
the rest of the code more linear.

Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: add `PhantomInvariant` and `PhantomInvariantLifetime`

Currently, the `pin_init` library has an `Invariant` type alias, and it is
instantiated using `PhantomData`. Generated

rust: pin-init: internal: add `PhantomInvariant` and `PhantomInvariantLifetime`

Currently, the `pin_init` library has an `Invariant` type alias, and it is
instantiated using `PhantomData`. Generated code from `pin_data` on the
other hand cannot access the crate-local type alias, so it generates
`PhantomData<fn(T) -> T>` directly. This is all very inconsistent, despite
the exact same use case of ensuring invariance.

Add `PhantomInvariant` and `PhantomInvariantLifetime` and switch all users
that need to express the concept of invariance to use these. They're
polyfills of unstable types in the same names in the Rust standard library.

Link: https://patch.msgid.link/20260512-pin-init-sync-v1-3-81963130dfbd@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: pin_data: add struct to record field info

Introduce `FieldInfo` struct to encapsulate field and other relevant data,
instead of carrying a pair of `(pinned, field)` in all

rust: pin-init: internal: pin_data: add struct to record field info

Introduce `FieldInfo` struct to encapsulate field and other relevant data,
instead of carrying a pair of `(pinned, field)` in all places. This allows
us to add more information to the struct in the future.

Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>
Co-developed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260512-pin-init-sync-v1-2-81963130dfbd@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: pin_data: use closure for `handle_field`

`handle_field` is currently a function, which precludes it from referencing
things in the scope of the parent function. Given that

rust: pin-init: internal: pin_data: use closure for `handle_field`

`handle_field` is currently a function, which precludes it from referencing
things in the scope of the parent function. Given that it's only called
once, inline its contents to the closure that invokes it instead, so it can
directly reference `struct_name` without having to pass in as argument.

Link: https://patch.msgid.link/20260512-pin-init-sync-v1-1-81963130dfbd@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: examples: fix `useless_borrows_in_formatting` clippy warning

Clippy 1.97 introduces new `useless_borrows_in_formatting` warning which
fires on the examples as we have `&*expr` where

rust: pin-init: examples: fix `useless_borrows_in_formatting` clippy warning

Clippy 1.97 introduces new `useless_borrows_in_formatting` warning which
fires on the examples as we have `&*expr` where the format macro takes
reference already. Remove the extra borrow.

Link: https://patch.msgid.link/20260505115138.2466966-1-gary@kernel.org
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: remove `collect_tuple` polyfill after MSRV bump

Tuples implement `FromIterator` since Rust 1.79. Remove the `collect_tuple`
polyfill now the MSRV is above 1.79.

To avoid o

rust: pin-init: internal: remove `collect_tuple` polyfill after MSRV bump

Tuples implement `FromIterator` since Rust 1.79. Remove the `collect_tuple`
polyfill now the MSRV is above 1.79.

To avoid over-identing the closure, I move the `Field` destructure from the
closure parameter to a let binding. This keeps the diff small.

Link: https://patch.msgid.link/20260501134445.3809731-1-gary@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: turn `PhantomPinned` error into warnings

The `PhantomPinned` detection is just a lint, and is emitted as an error
because there is no `compile_warning!()` macro, and
`proc-

rust: pin-init: internal: turn `PhantomPinned` error into warnings

The `PhantomPinned` detection is just a lint, and is emitted as an error
because there is no `compile_warning!()` macro, and
`proc-macro-diagnostics` is not stable.

Use of `#[deprecated = ""]` attribute to approximate custom proc-macro
warnings. A new line is added before message for visual clarity.

An example warning with this trick looks like this:

warning: use of deprecated function `_::warn`:
The field `pin` of type `PhantomPinned` only has an effect if it has the `#[pin]` attribute
--> test.rs:9:5
|
9 | pin: marker::PhantomPinned,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Suggested-by: Benno Lossin <lossin@kernel.org>
Link: https://github.com/Rust-for-Linux/pin-init/issues/51
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-10-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: cleanup workaround for old Rust compiler

The workaround mentions it's for Rust versions before 1.81. The minimum is
now 1.82, thus clean up.

Link: https://patch.msgid.link/20260428-

rust: pin-init: cleanup workaround for old Rust compiler

The workaround mentions it's for Rust versions before 1.81. The minimum is
now 1.82, thus clean up.

Link: https://patch.msgid.link/20260428-pin-init-sync-v1-9-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: fix badge URL in README

The old CI workflow has been deleted ~1 year ago. Fix the URL to point to
the correct one.

Link: https://patch.msgid.link/20260428-pin-init-sync-v1-8-07f9bd3

rust: pin-init: fix badge URL in README

The old CI workflow has been deleted ~1 year ago. Fix the URL to point to
the correct one.

Link: https://patch.msgid.link/20260428-pin-init-sync-v1-8-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: adjust license identifier of `zeroable.rs`

The pin-init crate has been licensed under `Apache-2.0 OR MIT` since the
beginning. I introduced in commit 071cedc84e90 ("rust: a

rust: pin-init: internal: adjust license identifier of `zeroable.rs`

The pin-init crate has been licensed under `Apache-2.0 OR MIT` since the
beginning. I introduced in commit 071cedc84e90 ("rust: add derive macro for
`Zeroable`") `zeroable.rs` with incompatible GPL-2.0 SPDX identifier. The
file has not been modified by other authors, so relicense it under the
above license.

Signed-off-by: Benno Lossin <lossin@kernel.org>
[ Reworded commit message - Gary ]
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-7-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: remove redundant `#[pin]` filtering

The `generate_projections` and `generate_the_pin_data` function already
receive filtered field lists, they do not need to filter out `#[

rust: pin-init: internal: remove redundant `#[pin]` filtering

The `generate_projections` and `generate_the_pin_data` function already
receive filtered field lists, they do not need to filter out `#[pin]`
again.

Reviewed-by: Benno Lossin <lossin@kernel.org>
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-6-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: internal: add missing where clause to projection types

`#[pin_data]` failed to propagate the struct's `where` clause to the
generated projection struct. As a result, bounds written i

rust: pin-init: internal: add missing where clause to projection types

`#[pin_data]` failed to propagate the struct's `where` clause to the
generated projection struct. As a result, bounds written in a `where`
clause could be dropped during expansion, causing type errors when
fields depended on those bounds.

Fix this by adding the missing `where` clause to the generated
projection struct.

Reported-by: Andreas Hindborg <a.hindborg@kernel.org>
Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/561532-pin-init/topic/generic.20bounds.20and.20.60.23.5Bpin_data.5D.60/with/578381591
Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>
Reviewed-by: Gary Guo <gary@garyguo.net>
[ Reworded commit message - Gary ]
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-5-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: extend `impl_zeroable_option` macro to handle generics

Improve impl_zeroable_option macro to handle generic impls for types
like `&T`, `&mut T`, `NonNull<T>`, and others (for which `

rust: pin-init: extend `impl_zeroable_option` macro to handle generics

Improve impl_zeroable_option macro to handle generic impls for types
like `&T`, `&mut T`, `NonNull<T>`, and others (for which `Option<T>`
is guaranteed to be zeroable) with similar approach to
`impl_zeroable`.

Also, update old declarations to use generics e.g. `NonZeroU8` to
`NonZero<u8>`.

Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-4-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...

rust: pin-init: cleanup `Zeroable` and `ZeroableOptions`

Place definitions and implementations (incl. macro invocations) of
the `Zeroable` trait first in the relevant section of `src/lib.rs`,
follow

rust: pin-init: cleanup `Zeroable` and `ZeroableOptions`

Place definitions and implementations (incl. macro invocations) of
the `Zeroable` trait first in the relevant section of `src/lib.rs`,
followed by the ZeroableOption trait and its implementations.

Rename `impl_non_zero_int_zeroable_option` to `impl_zeroable_option`
for consistency.

This commit should not introduce any functional changes.

Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-3-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>

show more ...