kernel/linux.git/rust/pin-init/src, branch v7.0-rc7

rust: pin-init: replace shadowed return token by `unsafe`-to-create token

2026-03-12T07:46:17+00:00

We use a unit struct `__InitOk` in the closure generated by the initializer macros as the return value. We shadow it by creating a struct with the same name again inside of the closure, preventing early returns of `Ok` in the initializer (before all fields have been initialized). In the face of Type Alias Impl Trait (TAIT) and the next trait solver, this solution no longer works [1]. The shadowed struct can be named through type inference. In addition, there is an RFC proposing to add the feature of path inference to Rust, which would similarly allow [2]. Thus remove the shadowed token and replace it with an `unsafe` to create token. The reason we initially used the shadowing solution was because an alternative solution used a builder pattern. Gary writes [3]: In the early builder-pattern based InitOk, having a single InitOk type for token is unsound because one can launder an InitOk token used for one place to another initializer. I used a branded lifetime solution, and then you figured out that using a shadowed type would work better because nobody could construct it at all. The laundering issue does not apply to the approach we ended up with today. With this change, the example by Tim Chirananthavat in [1] no longer compiles and results in this error: error: cannot construct `pin_init::__internal::InitOk` with struct literal syntax due to private fields --> src/main.rs:26:17 | 26 | InferredType {} | ^^^^^^^^^^^^ | = note: private field `0` that was not provided help: you might have meant to use the `new` associated function | 26 - InferredType {} 26 + InferredType::new() | Applying the suggestion of using the `::new()` function, results in another expected error: error[E0133]: call to unsafe function `pin_init::__internal::InitOk::new` is unsafe and requires unsafe block --> src/main.rs:26:17 | 26 | InferredType::new() | ^^^^^^^^^^^^^^^^^^^ call to unsafe function | = note: consult the function's documentation for information on how to avoid undefined behavior Reported-by: Tim Chirananthavat Link: https://github.com/rust-lang/rust/issues/153535 [1] Link: https://github.com/rust-lang/rfcs/pull/3444#issuecomment-4016145373 [2] Link: https://github.com/rust-lang/rust/issues/153535#issuecomment-4017620804 [3] Fixes: fc6c6baa1f40 ("rust: init: add initialization macros") Cc: stable@vger.kernel.org Signed-off-by: Benno Lossin Reviewed-by: Alice Ryhl Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260311105056.1425041-1-lossin@kernel.org [ Added period as mentioned. - Miguel ] Signed-off-by: Miguel Ojeda

Merge tag 'rust-fixes-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux

2026-02-22T16:43:31+00:00

Pull rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Pass '-Zunstable-options' flag required by the future Rust 1.95.0 - Fix 'objtool' warning for Rust 1.84.0 'kernel' crate: - 'irq' module: add missing bound detected by the future Rust 1.95.0 - 'list' module: add missing 'unsafe' blocks and placeholder safety comments to macros (an issue for future callers within the crate) 'pin-init' crate: - Clean Clippy warning that changed behavior in the future Rust 1.95.0" * tag 'rust-fixes-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: rust: list: Add unsafe blocks for container_of and safety comments rust: pin-init: replace clippy `expect` with `allow` rust: irq: add `'static` bounds to irq callbacks objtool/rust: add one more `noreturn` Rust function rust: kbuild: pass `-Zunstable-options` for Rust 1.95.0

rust: pin-init: replace clippy `expect` with `allow`

2026-02-19T08:33:43+00:00

`clippy` has changed behavior in [1] (Rust 1.95) where it no longer warns about the `let_and_return` lint when a comment is placed between the let binding and the return expression. Nightly thus fails to build, because the expectation is no longer fulfilled. Thus replace the expectation with an `allow`. [ The errors were: error: this lint expectation is unfulfilled --> rust/pin-init/src/lib.rs:1279:10 | 1279 | #[expect(clippy::let_and_return)] | ^^^^^^^^^^^^^^^^^^^^^^ | = note: `-D unfulfilled-lint-expectations` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unfulfilled_lint_expectations)]` error: this lint expectation is unfulfilled --> rust/pin-init/src/lib.rs:1295:10 | 1295 | #[expect(clippy::let_and_return)] | ^^^^^^^^^^^^^^^^^^^^^^ - Miguel ] Link: https://github.com/rust-lang/rust-clippy/pull/16461 [1] Signed-off-by: Benno Lossin Cc: stable@vger.kernel.org # Needed in 6.18.y and later. Link: https://patch.msgid.link/20260215132232.1549861-1-lossin@kernel.org Signed-off-by: Miguel Ojeda

rust: pin-init: Implement `InPlaceWrite` for `&'static mut MaybeUninit`

2026-01-17T09:53:28+00:00

This feature allows users to use `&'static mut MaybeUninit` as a place to initialize the value. It mirrors an existing implemetation for `Box`, but enables users to use external allocation mechanisms such as `static_cell` [1]. Signed-off-by: Oleksandr Babak Link: https://crates.io/crates/static_cell [1] [ Added link to `static_cell` - Benno ] Signed-off-by: Benno Lossin

rust: pin-init: rewrite the initializer macros using `syn`

2026-01-17T09:51:42+00:00

Rewrite the initializer macros `[pin_]init!` using `syn`. No functional changes intended aside from improved error messages on syntactic and semantical errors. For example if one forgets to use `<-` with an initializer (and instead uses `:`): impl Bar { fn new() -> impl PinInit { ... } } impl Foo { fn new() -> impl PinInit { pin_init!(Self { bar: Bar::new() }) } } Then the declarative macro would report: error[E0308]: mismatched types --> tests/ui/compile-fail/init/colon_instead_of_arrow.rs:21:9 | 14 | fn new() -> impl PinInit { | ------------------ the found opaque type ... 21 | pin_init!(Self { bar: Bar::new() }) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | | | expected `Bar`, found opaque type | arguments to this function are incorrect | = note: expected struct `Bar` found opaque type `impl pin_init::PinInit` note: function defined here --> $RUST/core/src/ptr/mod.rs | | pub const unsafe fn write(dst: *mut T, src: T) { | ^^^^^ = note: this error originates in the macro `$crate::__init_internal` which comes from the expansion of the macro `pin_init` (in Nightly builds, run with -Z macro-backtrace for more info) And the new error is: error[E0308]: mismatched types --> tests/ui/compile-fail/init/colon_instead_of_arrow.rs:21:31 | 14 | fn new() -> impl PinInit { | ------------------ the found opaque type ... 21 | pin_init!(Self { bar: Bar::new() }) | --- ^^^^^^^^^^ expected `Bar`, found opaque type | | | arguments to this function are incorrect | = note: expected struct `Bar` found opaque type `impl pin_init::PinInit` note: function defined here --> $RUST/core/src/ptr/mod.rs | | pub const unsafe fn write(dst: *mut T, src: T) { | ^^^^^ Importantly, this error gives much more accurate span locations, pointing to the offending field, rather than the entire macro invocation. Tested-by: Andreas Hindborg Reviewed-by: Gary Guo Signed-off-by: Benno Lossin

rust: pin-init: rewrite `#[pin_data]` using `syn`

2026-01-17T09:51:42+00:00

Rewrite the attribute macro `#[pin_data]` using `syn`. No functional changes intended aside from improved error messages on syntactic and semantical errors. For example if one forgets a comma at the end of a field: #[pin_data] struct Foo { a: Box b: Box } The declarative macro reports the following errors: error: expected `,`, or `}`, found `b` --> tests/ui/compile-fail/pin_data/missing_comma.rs:5:16 | 5 | a: Box | ^ help: try adding a comma: `,` error: recursion limit reached while expanding `$crate::__pin_data!` --> tests/ui/compile-fail/pin_data/missing_comma.rs:3:1 | 3 | #[pin_data] | ^^^^^^^^^^^ | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`$CRATE`) = note: this error originates in the macro `$crate::__pin_data` which comes from the expansion of the attribute macro `pin_data` (in Nightly builds, run with -Z macro-backtrace for more info) The new `syn` version reports: error: expected `,`, or `}`, found `b` --> tests/ui/compile-fail/pin_data/missing_comma.rs:5:16 | 5 | a: Box | ^ help: try adding a comma: `,` error: expected `,` --> tests/ui/compile-fail/pin_data/missing_comma.rs:6:5 | 6 | b: Box | ^ Tested-by: Andreas Hindborg Reviewed-by: Gary Guo Signed-off-by: Benno Lossin

rust: pin-init: rewrite the `#[pinned_drop]` attribute macro using `syn`

2026-01-17T09:51:42+00:00

Rewrite the attribute macro for implementing `PinnedDrop` using `syn`. Otherwise no functional changes intended aside from improved error messages on syntactic and semantical errors. For example: When missing the `drop` function in the implementation, the old error was: error: no rules expected `)` --> tests/ui/compile-fail/pinned_drop/no_fn.rs:6:1 | 6 | #[pinned_drop] | ^^^^^^^^^^^^^^ no rules expected this token in macro call | note: while trying to match keyword `fn` --> src/macros.rs | | fn drop($($sig:tt)*) { | ^^ = note: this error originates in the attribute macro `pinned_drop` (in Nightly builds, run with -Z macro-backtrace for more info) And the new one is: error[E0046]: not all trait items implemented, missing: `drop` --> tests/ui/compile-fail/pinned_drop/no_fn.rs:7:1 | 7 | impl PinnedDrop for Foo {} | ^^^^^^^^^^^^^^^^^^^^^^^ missing `drop` in implementation | = help: implement the missing item: `fn drop(self: Pin<&mut Self>, _: OnlyCallFromDrop) { todo!() }` Tested-by: Andreas Hindborg Reviewed-by: Gary Guo Signed-off-by: Benno Lossin

rust: pin-init: rewrite `derive(Zeroable)` and `derive(MaybeZeroable)` using `syn`

2026-01-17T09:51:42+00:00

Rewrite the two derive macros for `Zeroable` using `syn`. One positive side effect of this change is that tuple structs are now supported by them. Additionally, syntax errors and the error emitted when trying to use one of the derive macros on an `enum` are improved. Otherwise no functional changes intended. For example: #[derive(Zeroable)] enum Num { A(u32), B(i32), } Produced this error before this commit: error: no rules expected keyword `enum` --> tests/ui/compile-fail/zeroable/enum.rs:5:1 | 5 | enum Num { | ^^^^ no rules expected this token in macro call | note: while trying to match keyword `struct` --> src/macros.rs | | $vis:vis struct $name:ident | ^^^^^^ Now the error is: error: cannot derive `Zeroable` for an enum --> tests/ui/compile-fail/zeroable/enum.rs:5:1 | 5 | enum Num { | ^^^^ error: cannot derive `Zeroable` for an enum Tested-by: Andreas Hindborg Reviewed-by: Gary Guo Signed-off-by: Benno Lossin

rust: pin-init: allow the crate to refer to itself as `pin-init` in doc tests

2026-01-17T09:49:31+00:00

The `syn` approach requires use of `::pin_init::...` instead of the `$crate::...` construct available to declarative macros. To be able to use the `pin_init` crate from itself (which includes doc tests), we have to declare it as such. Reviewed-by: Gary Guo Tested-by: Andreas Hindborg Signed-off-by: Benno Lossin

rust: pin-init: remove `try_` versions of the initializer macros

2026-01-17T09:49:31+00:00

The `try_[pin_]init!` versions of the initializer macros are superfluous. Instead of forcing the user to always write an error in `try_[pin_]init!` and not allowing one in `[pin_]init!`, combine them into `[pin_]init!` that defaults the error to `core::convert::Infallible`, but also allows to specify a custom one. Projects using pin-init still can provide their own defaulting initializers using the `try_` prefix by using the `#[default_error]` attribute added in a future patch. [ Adjust the definition of the kernel's version of the `try_` initializer macros - Benno] Reviewed-by: Gary Guo Tested-by: Andreas Hindborg Signed-off-by: Benno Lossin