Changes in init.rs

50c8f83c41123cab79575e8d73040a37da4612c5 - Merge tag 'asoc-fix-v7.0-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

Fri, 27 Mar 2026 09:16:52 +0000

Merge tag 'asoc-fix-v7.0-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linusASoC: Fixes for v7.0This is two week's worth of fixes and quirks so it's a bit larger thanyou might expect, there's nothing too exciting individually and nothingin core code. List of files: /linux/rust/pin-init/internal/src/init.rs

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

Sat, 14 Mar 2026 19:35:16 +0000

Merge tag 'rust-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linuxPull Rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Remap paths to avoid absolute ones starting with the upcoming Rust 1.95.0 release. This improves build reproducibility, avoids leaking the exact path and avoids having the same path appear in two forms The approach here avoids remapping debug information as well, in order to avoid breaking tools that used the paths to access source files, which was the previous attempt that needed to be reverted - Allow 'unused_features' lint for the upcoming Rust 1.96.0 release. While well-intentioned, we do not benefit much from the new lint - Emit dependency information into '$(depfile)' directly to avoid a temporary '.d' file (it was an old approach) 'kernel' crate: - 'str' module: fix warning under '!CONFIG_BLOCK' by making 'NullTerminatedFormatter' public - 'cpufreq' module: suppress false positive Clippy warning 'pin-init' crate: - Remove '#[disable_initialized_field_access]' attribute which was unsound. This means removing the support for structs with unaligned fields (through the 'repr(packed)' attribute), for now And document the load-bearing fact of field accessors (i.e. that they are required for soundness) - Replace shadowed return token by 'unsafe'-to-create token in order to remain sound in the face of the likely upcoming Type Alias Impl Trait (TAIT) and the next trait solver in upstream Rust"* tag 'rust-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: rust: kbuild: allow `unused_features` rust: cpufreq: suppress clippy::double_parens in Policy doctest rust: pin-init: replace shadowed return token by `unsafe`-to-create token rust: pin-init: internal: init: document load-bearing fact of field accessors rust: pin-init: internal: init: remove `#[disable_initialized_field_access]` rust: build: remap path to avoid absolute path rust: kbuild: emit dep-info into $(depfile) directly rust: str: make NullTerminatedFormatter public List of files: /linux/rust/pin-init/internal/src/init.rs

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

Wed, 11 Mar 2026 10:50:49 +0000

rust: pin-init: replace shadowed return token by `unsafe`-to-create tokenWe use a unit struct `__InitOk` in the closure generated by theinitializer macros as the return value. We shadow it by creating astruct with the same name again inside of the closure, preventing earlyreturns of `Ok` in the initializer (before all fields have beeninitialized).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 namedthrough type inference. In addition, there is an RFC proposing to addthe feature of path inference to Rust, which would similarly allow [2].Thus remove the shadowed token and replace it with an `unsafe` to createtoken.The reason we initially used the shadowing solution was because analternative 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 withtoday.With this change, the example by Tim Chirananthavat in [1] no longercompiles 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 inanother 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 behaviorReported-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.orgSigned-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 List of files: /linux/rust/pin-init/internal/src/init.rs

580cc37b1de4fcd9997c48d7080e744533f09f36 - rust: pin-init: internal: init: document load-bearing fact of field accessors

Mon, 02 Mar 2026 14:04:15 +0000

rust: pin-init: internal: init: document load-bearing fact of field accessorsThe functions `[Pin]Init::__[pinned_]init` and `ptr::write` called fromthe `init!` macro require the passed pointer to be aligned. This fact isensured by the creation of field accessors to previously initializedfields.Since we missed this very important fact from the beginning [1],document it in the code.Link: https://rust-for-linux.zulipchat.com/#narrow/channel/561532-pin-init/topic/initialized.20field.20accessor.20detection/with/576210658 [1]Fixes: 90e53c5e70a6 ("rust: add pin-init API core")Cc: # 6.6.y, 6.12.y: 42415d163e5d: rust: pin-init: add references to previously initialized fieldsCc: # 6.6.y, 6.12.y, 6.18.y, 6.19.ySigned-off-by: Benno Lossin Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260302140424.4097655-2-lossin@kernel.org[ Updated Cc: stable@ tags as discussed. - Miguel ]Signed-off-by: Miguel Ojeda List of files: /linux/rust/pin-init/internal/src/init.rs

a075082a15e7f5c4889d0cbb51a4041c332cb00c - rust: pin-init: internal: init: remove `#[disable_initialized_field_access]`

Mon, 02 Mar 2026 14:04:14 +0000

rust: pin-init: internal: init: remove `#[disable_initialized_field_access]`Gary noticed [1] that the initializer macros as well as the `[Pin]Init`traits cannot support unaligned fields, since they use operations thatrequire aligned pointers. This means that any code using structs withunaligned fields in pin-init is unsound.By default, the `init!` macro generates references to initialized fields,which makes the compiler check that those fields are aligned. However,we added the `#[disable_initialized_field_access]` attribute to avoidthis behavior in commit ceca298c53f9 ("rust: pin-init: internal: init:add escape hatch for referencing initialized fields"). Thus remove the`#[disable_initialized_field_access]` attribute from `init!`, which isthe only safe way to create an initializer handling unaligned fields.If support for in-place initializing structs with unaligned fields isrequired in the future, we could figure out a solution. This is trackedin [2].Reported-by: Gary Guo Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/561532-pin-init/topic/initialized.20field.20accessor.20detection/with/576210658 [1]Link: https://github.com/Rust-for-Linux/pin-init/issues/112 [2]Fixes: ceca298c53f9 ("rust: pin-init: internal: init: add escape hatch for referencing initialized fields")Signed-off-by: Benno Lossin Acked-by: Janne Grunau Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260302140424.4097655-1-lossin@kernel.org[ Adjusted tags and reworded as discussed. - Miguel ]Signed-off-by: Miguel Ojeda List of files: /linux/rust/pin-init/internal/src/init.rs

c17ee635fd3a482b2ad2bf5e269755c2eae5f25e - Merge drm/drm-fixes into drm-misc-fixes

Mon, 23 Feb 2026 09:09:45 +0000

Merge drm/drm-fixes into drm-misc-fixes7.0-rc1 was just released, let's merge it to kick the new release cycle.Signed-off-by: Maxime Ripard List of files: /linux/rust/pin-init/internal/src/init.rs

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

Tue, 10 Feb 2026 19:53:01 +0000

Merge tag 'rust-6.20-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linuxPull rust updates from Miguel Ojeda: "Toolchain and infrastructure: - Add '__rust_helper' annotation to the C helpers This is needed to inline these helpers into Rust code - Remove imports available via the prelude, treewide This was possible thanks to a new lint in Klint that Gary has implemented -- more Klint-related changes, including initial upstream support, are coming - Deduplicate pin-init flags 'kernel' crate: - Add support for calling a function exactly once with the new 'do_once_lite!' macro (and 'OnceLite' type) Based on this, add 'pr_*_once!' macros to print only once - Add 'impl_flags!' macro for defining common bitflags operations: impl_flags!( /// Represents multiple permissions. #[derive(Debug, Clone, Default, Copy, PartialEq, Eq)] pub struct Permissions(u32); /// Represents a single permission. #[derive(Debug, Clone, Copy, PartialEq, Eq)] pub enum Permission { /// Read permission. Read = 1 << 0, /// Write permission. Write = 1 << 1, /// Execute permission. Execute = 1 << 2, } ); let mut f: Permissions = Permission::Read | Permission::Write; assert!(f.contains(Permission::Read)); assert!(!f.contains(Permission::Execute)); f |= Permission::Execute; assert!(f.contains(Permission::Execute)); let f2: Permissions = Permission::Write | Permission::Execute; assert!((f ^ f2).contains(Permission::Read)); assert!(!(f ^ f2).contains(Permission::Write)); - 'bug' module: support 'CONFIG_DEBUG_BUGVERBOSE_DETAILED' in the 'warn_on!' macro in order to show the evaluated condition alongside the file path: ------------[ cut here ]------------ WARNING: [val == 1] linux/samples/rust/rust_minimal.rs:27 at ... Modules linked in: rust_minimal(+) - Add safety module with 'unsafe_precondition_assert!' macro, currently a wrapper for 'debug_assert!', intended to mark the validation of safety preconditions where possible: /// # Safety /// /// The caller must ensure that `index` is less than `N`. unsafe fn set_unchecked(&mut self, index: usize, value: T) { unsafe_precondition_assert!( index < N, "set_unchecked() requires index ({index}) < N ({N})" ); ... } - Add instructions to 'build_assert!' documentation requesting to always inline functions when used with function arguments - 'ptr' module: replace 'build_assert!' with a 'const' one - 'rbtree' module: reduce unsafe blocks on pointer derefs - 'transmute' module: implement 'FromBytes' and 'AsBytes' for inhabited ZSTs, and use it in Nova - More treewide replacements of 'c_str!' with C string literals 'macros' crate: - Rewrite most procedural macros ('module!', 'concat_idents!', '#[export]', '#[vtable]', '#[kunit_tests]') to use the 'syn' parsing library which we introduced last cycle, with better diagnostics This also allows to support '#[cfg]' properly in the '#[vtable]' macro, to support arbitrary types in 'module!' macro (not just an identifier) and to remove several custom parsing helpers we had - Use 'quote!' from the recently vendored 'quote' library and remove our custom one The vendored one also allows us to avoid quoting '"' and '{}' inside the template anymore and editors can now highlight it. In addition, it improves robustness as it eliminates the need for string quoting and escaping - Use 'pin_init::zeroed()' to simplify KUnit code 'pin-init' crate: - Rewrite all procedural macros ('[pin_]init!', '#[pin_data]', '#[pinned_drop]', 'derive([Maybe]Zeroable)') to use the 'syn' parsing library which we introduced last cycle, with better diagnostics - Implement 'InPlaceWrite' for '&'static mut MaybeUninit'. This enables users to use external allocation mechanisms such as 'static_cell' - Support tuple structs in 'derive([Maybe]Zeroable)' - Support attributes on fields in '[pin_]init!' (such as '#[cfg(...)]') - Add a '#[default_error()]' attribute to '[pin_]init!' to override the default error (when no '? Error' is specified) - Support packed structs in '[pin_]init!' with '#[disable_initialized_field_access]' - Remove 'try_[pin_]init!' in favor of merging their feature with '[pin_]init!'. Update the kernel's own 'try_[pin_]init!' macros to use the 'default_error' attribute - Correct 'T: Sized' bounds to 'T: ?Sized' in the generated 'PinnedDrop' check by '#[pin_data]' Documentation: - Conclude the Rust experiment MAINTAINERS: - Add "RUST [RUST-ANALYZER]" entry for the rust-analyzer support. Tamir and Jesung will take care of it. They have both been active around it for a while. The new tree will flow through the Rust one - Add Gary as maintainer for "RUST [PIN-INIT]" - Update Boqun and Tamir emails to their kernel.org accounts And a few other cleanups and improvements"* tag 'rust-6.20-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (59 commits) rust: safety: introduce `unsafe_precondition_assert!` macro rust: add `impl_flags!` macro for defining common bitflag operations rust: print: Add pr_*_once macros rust: bug: Support DEBUG_BUGVERBOSE_DETAILED option rust: print: Add support for calling a function exactly once rust: kbuild: deduplicate pin-init flags gpu: nova-core: remove imports available via prelude rust: clk: replace `kernel::c_str!` with C-Strings MAINTAINERS: Update my email address to @kernel.org rust: macros: support `#[cfg]` properly in `#[vtable]` macro. rust: kunit: use `pin_init::zeroed` instead of custom null value rust: macros: rearrange `#[doc(hidden)]` in `module!` macro rust: macros: allow arbitrary types to be used in `module!` macro rust: macros: convert `#[kunit_tests]` macro to use `syn` rust: macros: convert `concat_idents!` to use `syn` rust: macros: convert `#[export]` to use `syn` rust: macros: use `quote!` for `module!` macro rust: macros: use `syn` to parse `module!` macro rust: macros: convert `#[vtable]` macro to use `syn` rust: macros: use `quote!` from vendored crate ... List of files: /linux/rust/pin-init/internal/src/init.rs

99ba0fa10de0cc0386ea61e6e5068a78a8394060 - Merge tag 'pin-init-v7.0' of https://github.com/Rust-for-Linux/linux into rust-next

Tue, 27 Jan 2026 13:33:55 +0000

Merge tag 'pin-init-v7.0' of https://github.com/Rust-for-Linux/linux into rust-nextPull pin-init updates from Benno Lossin: "Added: - Implement 'InPlaceWrite' for '&'static mut MaybeUninit'. This enables users to use external allocation mechanisms such as 'static_cell'. - Add Gary Guo as a Maintainer. Changed: - Rewrote all proc-macros ('[pin_]init!', '#[pin_data]', '#[pinned_drop]', 'derive([Maybe]Zeroable)'), using 'syn' with better diagnostics. - Support tuple structs in 'derive([Maybe]Zeroable)'. - Support attributes on fields in '[pin_]init!' (such as '#[cfg(...)]'). - Add a '#[default_error()]' attribute to '[pin_]init!' to override the default error (when no '? Error' is specified). - Support packed structs in '[pin_]init!' with '#[disable_initialized_field_access]'. Removed: - Remove 'try_[pin_]init!' in favor of merging their feature with '[pin_]init!'. Update the kernel's own 'try_[pin_]init!' macros to use the 'default_error' attribute. Fixed: - Correct 'T: Sized' bounds to 'T: ?Sized' in the generated 'PinnedDrop' check by '#[pin_data]'."* tag 'pin-init-v7.0' of https://github.com/Rust-for-Linux/linux: rust: pin-init: Implement `InPlaceWrite` for `&'static mut MaybeUninit` MAINTAINERS: add Gary Guo to pin-init rust: pin-init: internal: init: simplify Zeroable safety check rust: pin-init: internal: init: add escape hatch for referencing initialized fields rust: pin-init: internal: init: add support for attributes on initializer fields rust: init: use `#[default_error(err)]` for the initializer macros rust: pin-init: add `#[default_error()]` attribute to initializer macros rust: pin-init: rewrite the initializer macros using `syn` rust: pin-init: add `?Sized` bounds to traits in `#[pin_data]` macro rust: pin-init: rewrite `#[pin_data]` using `syn` rust: pin-init: rewrite the `#[pinned_drop]` attribute macro using `syn` rust: pin-init: rewrite `derive(Zeroable)` and `derive(MaybeZeroable)` using `syn` rust: pin-init: internal: add utility API for syn error handling rust: pin-init: add `syn` dependency and remove `proc-macro[2]` and `quote` workarounds rust: pin-init: allow the crate to refer to itself as `pin-init` in doc tests rust: pin-init: remove `try_` versions of the initializer macros List of files: /linux/rust/pin-init/internal/src/init.rs

1f1cd6964bbc37f2cc82a0adc8a0acec34af1afb - rust: pin-init: internal: init: simplify Zeroable safety check

Fri, 16 Jan 2026 10:54:29 +0000

rust: pin-init: internal: init: simplify Zeroable safety checkThe `Zeroable` type check uses a small dance with a raw pointer to aidtype inference. It turns out that this is not necessary and typeinference is powerful enough to resolve any ambiguity. Thus remove it.Suggested-by: Gary Guo Tested-by: Andreas Hindborg Reviewed-by: Gary Guo Signed-off-by: Benno Lossin List of files: /linux/rust/pin-init/internal/src/init.rs

ceca298c53f9300ea689207f9ae9a3da3b4b4c4f - rust: pin-init: internal: init: add escape hatch for referencing initialized fields

Fri, 16 Jan 2026 10:54:28 +0000

rust: pin-init: internal: init: add escape hatch for referencing initialized fieldsThe initializer macro emits mutable references for already initializedfields, which allows modifying or accessing them later in code blocks orwhen initializing other fields. This behavior results in compiler errorswhen combining with packed structs, since those do not permit creatingreferences to misaligned fields. For example: #[repr(C, packed)] struct Foo { a: i8, b: i32, } fn main() { let _ = init!(Foo { a: -42, b: 42 }); }This will lead to an error like this: error[E0793]: reference to field of packed struct is unaligned --> tests/ui/compile-fail/init/packed_struct.rs:10:13 | 10 | let _ = init!(Foo { a: -42, b: 42 }); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: this struct is 1-byte aligned, but the type of this field may require higher alignment = note: creating a misaligned reference is undefined behavior (even if that reference is never dereferenced) = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers) = note: this error originates in the macro `init` (in Nightly builds, run with -Z macro-backtrace for more info)This was requested by Janne Grunau [1] and will most certainly be usedby the kernel when we eventually end up with trying to initialize packedstructs.Thus add an initializer attribute `#[disable_initialized_field_access]`that does what the name suggests: do not generate references to alreadyinitialized fields.There is space for future work: add yet another attribute which can beapplied on fields of initializers that ask for said field to be madeaccessible. We can add that when the need arises.Requested-by: Janne Grunau Link: https://lore.kernel.org/all/20251206170214.GE1097212@robin.jannau.net [1]Tested-by: Andreas Hindborg Reviewed-by: Gary Guo Signed-off-by: Benno Lossin List of files: /linux/rust/pin-init/internal/src/init.rs

d26732e57b06ef32dadfc32d5de9ac39262698cb - rust: pin-init: internal: init: add support for attributes on initializer fields

Fri, 16 Jan 2026 10:54:27 +0000

rust: pin-init: internal: init: add support for attributes on initializer fieldsInitializer fields ought to support the same attributes that are allowedin struct initializers on fields. For example, `cfg` or lint levels suchas `expect`, `allow` etc. Add parsing support for these attributes usingsyn to initializer fields and adjust the macro expansion accordingly.Tested-by: Andreas Hindborg Reviewed-by: Gary Guo Signed-off-by: Benno Lossin List of files: /linux/rust/pin-init/internal/src/init.rs

aeabc92eb2d8c27578274a7ec3d0d00558fedfc2 - rust: pin-init: add `#[default_error()]` attribute to initializer macros

Fri, 16 Jan 2026 10:54:25 +0000

rust: pin-init: add `#[default_error()]` attribute to initializer macrosThe `#[default_error()]` attribute can be used to supply a defaulttype as the error used for the `[pin_]init!` macros. This way one caneasily define custom `try_[pin_]init!` variants that default to yourproject specific error type. Just write the following declarative macro: macro_rules! try_init { ($($args:tt)*) => { ::pin_init::init!( #[default_error(YourCustomErrorType)] $($args)* ) } }Tested-by: Andreas Hindborg Reviewed-by: Gary Guo Signed-off-by: Benno Lossin List of files: /linux/rust/pin-init/internal/src/init.rs

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

Fri, 16 Jan 2026 10:54:24 +0000

rust: pin-init: rewrite the initializer macros using `syn`Rewrite the initializer macros `[pin_]init!` using `syn`. No functionalchanges intended aside from improved error messages on syntactic andsemantical errors. For example if one forgets to use `<-` with aninitializer (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 macroinvocation.Tested-by: Andreas Hindborg Reviewed-by: Gary Guo Signed-off-by: Benno Lossin List of files: /linux/rust/pin-init/internal/src/init.rs