| aeb5ecad | 08-Jan-2026 |
Oleksandr Babak <alexanderbabak@proton.me> |
rust: pin-init: Implement `InPlaceWrite<T>` for `&'static mut MaybeUninit<T>`
This feature allows users to use `&'static mut MaybeUninit<T>` as a
place to initialize the value. It mirrors an existin
rust: pin-init: Implement `InPlaceWrite<T>` for `&'static mut MaybeUninit<T>`
This feature allows users to use `&'static mut MaybeUninit<T>` as a
place to initialize the value. It mirrors an existing implemetation
for `Box<MaybeUninit>`, but enables users to use external allocation
mechanisms such as `static_cell` [1].
Signed-off-by: Oleksandr Babak <alexanderbabak@proton.me>
Link: https://crates.io/crates/static_cell [1]
[ Added link to `static_cell` - Benno ]
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| 4883830e | 16-Jan-2026 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: rewrite the initializer macros using `syn`
Rewrite the initializer macros `[pin_]init!` using `syn`. No functional
changes intended aside from improved error messages on syntactic an
rust: pin-init: rewrite the initializer macros using `syn`
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<Self> { ... }
}
impl Foo {
fn new() -> impl PinInit<Self> {
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<Self> {
| ------------------ 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<Bar>`
note: function defined here
--> $RUST/core/src/ptr/mod.rs
|
| pub const unsafe fn write<T>(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<Self> {
| ------------------ 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<Bar>`
note: function defined here
--> $RUST/core/src/ptr/mod.rs
|
| pub const unsafe fn write<T>(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 <a.hindborg@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| 560f6d13 | 16-Jan-2026 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: rewrite `#[pin_data]` using `syn`
Rewrite the attribute macro `#[pin_data]` using `syn`. No functional
changes intended aside from improved error messages on syntactic and
semantical
rust: pin-init: rewrite `#[pin_data]` using `syn`
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<Foo>
b: Box<Foo>
}
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<Foo>
| ^ 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<Foo>
| ^ help: try adding a comma: `,`
error: expected `,`
--> tests/ui/compile-fail/pin_data/missing_comma.rs:6:5
|
6 | b: Box<Foo>
| ^
Tested-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| a92f5fd2 | 16-Jan-2026 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: rewrite the `#[pinned_drop]` attribute macro using `syn`
Rewrite the attribute macro for implementing `PinnedDrop` using `syn`.
Otherwise no functional changes intended aside from im
rust: pin-init: rewrite the `#[pinned_drop]` attribute macro using `syn`
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 <a.hindborg@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| 50426bde | 16-Jan-2026 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: rewrite `derive(Zeroable)` and `derive(MaybeZeroable)` using `syn`
Rewrite the two derive macros for `Zeroable` using `syn`. One positive
side effect of this change is that tuple str
rust: pin-init: rewrite `derive(Zeroable)` and `derive(MaybeZeroable)` using `syn`
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 <a.hindborg@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| 901f1d73 | 16-Jan-2026 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: allow the crate to refer to itself as `pin-init` in doc tests
The `syn` approach requires use of `::pin_init::...` instead of the
`$crate::...` construct available to declarative mac
rust: pin-init: allow the crate to refer to itself as `pin-init` in doc tests
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 <gary@garyguo.net>
Tested-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| 42415d16 | 05-Sep-2025 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: add references to previously initialized fields
After initializing a field in an initializer macro, create a variable
holding a reference that points at that field. The type is eithe
rust: pin-init: add references to previously initialized fields
After initializing a field in an initializer macro, create a variable
holding a reference that points at that field. The type is either
`Pin<&mut T>` or `&mut T` depending on the field's structural pinning
kind.
[ Applied fixes to devres and rust_driver_pci sample - Benno]
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| 1fa51679 | 05-Sep-2025 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: add code blocks to `[try_][pin_]init!` macros
Allow writing `_: { /* any number of statements */ }` in initializers to
run arbitrary code during initialization.
try_init!(MyStru
rust: pin-init: add code blocks to `[try_][pin_]init!` macros
Allow writing `_: { /* any number of statements */ }` in initializers to
run arbitrary code during initialization.
try_init!(MyStruct {
_: {
if check_something() {
return Err(MyError);
}
},
foo: Foo::new(val),
_: {
println!("successfully initialized `MyStruct`");
},
})
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| 619db96d | 05-Sep-2025 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: add pin projections to `#[pin_data]`
Make the `#[pin_data]` macro generate a `*Projection` struct that holds
either `Pin<&mut Field>` or `&mut Field` for every field of the original
rust: pin-init: add pin projections to `#[pin_data]`
Make the `#[pin_data]` macro generate a `*Projection` struct that holds
either `Pin<&mut Field>` or `&mut Field` for every field of the original
struct. Which version is chosen depends on weather there is a `#[pin]`
or not respectively. Access to this projected version is enabled through
generating `fn project(self: Pin<&mut Self>) -> SelfProjection<'_>`.
[ Adapt workqueue to use the new projection instead of its own, custom
one - Benno ]
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| e8fa0481 | 13-Jul-2025 |
Miguel Ojeda <ojeda@kernel.org> |
Merge tag 'pin-init-v6.17' of https://github.com/Rust-for-Linux/linux into rust-next
Pull pin-init updates from Benno Lossin:
"Added:
- 'impl<T, E> [Pin]Init<T, E> for Result<T, E>', so results
Merge tag 'pin-init-v6.17' of https://github.com/Rust-for-Linux/linux into rust-next
Pull pin-init updates from Benno Lossin:
"Added:
- 'impl<T, E> [Pin]Init<T, E> for Result<T, E>', so results are now
(pin-)initializers.
- 'Zeroable::init_zeroed()' delegating to 'init_zeroed()'.
- New 'zeroed()', a safe version of 'mem::zeroed()' and also provide
it via 'Zeroable::zeroed()'.
- Implement 'Zeroable' for 'Option<&T>' and 'Option<&mut T>'.
- Implement 'Zeroable' for 'Option<[unsafe] [extern "abi"]
fn(...args...) -> ret>' for '"Rust"' and '"C"' ABIs and up to 20
arguments.
Changed:
- Blanket impls of 'Init' and 'PinInit' from 'impl<T, E>
[Pin]Init<T, E> for T' to 'impl<T> [Pin]Init<T> for T'.
- Renamed 'zeroed()' to 'init_zeroed()'.
Upstream dev news:
- More CI improvements to deny warnings, use '--all-targets'. Also
check the synchronization status of the two '-next' branches in
upstream and the kernel."
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
* tag 'pin-init-v6.17' of https://github.com/Rust-for-Linux/linux:
rust: pin-init: examples, tests: use `ignore` instead of conditionally compiling tests
rust: init: remove doctest's `Error::from_errno` workaround
rust: init: re-enable doctests
rust: pin-init: implement `ZeroableOption` for function pointers with up to 20 arguments
rust: pin-init: change `impl Zeroable for Option<NonNull<T>>` to `ZeroableOption for NonNull<T>`
rust: pin-init: implement `ZeroableOption` for `&T` and `&mut T`
rust: pin-init: add `zeroed()` & `Zeroable::zeroed()` functions
rust: pin-init: add `Zeroable::init_zeroed`
rust: pin-init: rename `zeroed` to `init_zeroed`
rust: pin-init: feature-gate the `stack_init_reuse` test on the `std` feature
rust: pin-init: examples: pthread_mutex: disable the main test for miri
rust: pin-init: examples, tests: add conditional compilation in order to compile under any feature combination
rust: pin-init: change blanket impls for `[Pin]Init` and add one for `Result<T, E>`
rust: pin-init: improve safety documentation for `impl<T> [Pin]Init<T> for T`
show more ...
|
| ec87ec35 | 23-May-2025 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: implement `ZeroableOption` for function pointers with up to 20 arguments
`Option<[unsafe] [extern "abi"] fn(...args...) -> ret>` is documented
[1] to also have the `None` variant equ
rust: pin-init: implement `ZeroableOption` for function pointers with up to 20 arguments
`Option<[unsafe] [extern "abi"] fn(...args...) -> ret>` is documented
[1] to also have the `None` variant equal all zeroes.
Link: https://doc.rust-lang.org/stable/std/option/index.html#representation [1]
Link: https://github.com/Rust-for-Linux/pin-init/pull/56/commits/b6c1ab4fb3699765f81ae512ecac5a2f032d8d51
Link: https://lore.kernel.org/all/20250523145125.523275-7-lossin@kernel.org
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| 9f473538 | 23-May-2025 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: change `impl Zeroable for Option<NonNull<T>>` to `ZeroableOption for NonNull<T>`
This brings it in line with references. It too is listed in [1].
Link: https://doc.rust-lang.org/sta
rust: pin-init: change `impl Zeroable for Option<NonNull<T>>` to `ZeroableOption for NonNull<T>`
This brings it in line with references. It too is listed in [1].
Link: https://doc.rust-lang.org/stable/std/option/index.html#representation
Link: https://github.com/Rust-for-Linux/pin-init/pull/56/commits/8e52bf56ddc2190ce901d2f7c008ab8a64f653a9
Link: https://lore.kernel.org/all/20250523145125.523275-6-lossin@kernel.org
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| e93a2386 | 23-May-2025 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: implement `ZeroableOption` for `&T` and `&mut T`
`Option<&T>` and `Option<&mut T>` are documented [1] to have the `None`
variant be all zeroes.
Link: https://doc.rust-lang.org/stabl
rust: pin-init: implement `ZeroableOption` for `&T` and `&mut T`
`Option<&T>` and `Option<&mut T>` are documented [1] to have the `None`
variant be all zeroes.
Link: https://doc.rust-lang.org/stable/std/option/index.html#representation [1]
Link: https://github.com/Rust-for-Linux/pin-init/pull/56/commits/5ef1638c79e019d3dc0c62db5905601644c2e60a
Link: https://lore.kernel.org/all/20250523145125.523275-5-lossin@kernel.org
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| d67b3701 | 23-May-2025 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: add `zeroed()` & `Zeroable::zeroed()` functions
`zeroed()` returns a zeroed out value of a sized type implementing
`Zeroable`.
The function is added as a free standing function, in
rust: pin-init: add `zeroed()` & `Zeroable::zeroed()` functions
`zeroed()` returns a zeroed out value of a sized type implementing
`Zeroable`.
The function is added as a free standing function, in addition to an
associated function on `Zeroable`, because then it can be marked `const`
(functions in traits can't be const at the moment).
Link: https://github.com/Rust-for-Linux/pin-init/pull/56/commits/809e4ec160579c1601dce5d78b432a5b6c8e4e40
Link: https://lore.kernel.org/all/20250523145125.523275-4-lossin@kernel.org
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| c47024ba | 23-May-2025 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: add `Zeroable::init_zeroed`
The trait function delegates to the already existing `init_zeroed`
function that returns a zeroing initializer for `Self`.
The syntax `..Zeroable::init_z
rust: pin-init: add `Zeroable::init_zeroed`
The trait function delegates to the already existing `init_zeroed`
function that returns a zeroing initializer for `Self`.
The syntax `..Zeroable::init_zeroed()` is already used by the
initialization macros to initialize all fields that are not mentioned in
the initializer with zero. Therefore it is expected that the function
also exists on the trait.
Link: https://github.com/Rust-for-Linux/pin-init/pull/56/commits/a424a6c9af5a4418a8e5e986a3db26a4432e2f1a
Link: https://lore.kernel.org/all/20250523145125.523275-3-lossin@kernel.org
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| b3b4f760 | 09-Jun-2025 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: feature-gate the `stack_init_reuse` test on the `std` feature
When trying to run `cargo check --all-targets --no-default-features`, an
error is reported by the test, as it cannot fin
rust: pin-init: feature-gate the `stack_init_reuse` test on the `std` feature
When trying to run `cargo check --all-targets --no-default-features`, an
error is reported by the test, as it cannot find the `std` crate. This
is to be expected, since the `--no-default-features` flag enables the
`no-std` behavior of the crate. Thus exclude the test in that scenario.
Link: https://github.com/Rust-for-Linux/pin-init/pull/50/commits/2813729ccacdedee9dbfcab1ed285b8721a0391b
Link: https://lore.kernel.org/all/20250523125424.192843-4-lossin@kernel.org
[ Changed my author email address to @kernel.org. - Benno ]
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| e832374c | 29-May-2025 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: change blanket impls for `[Pin]Init` and add one for `Result<T, E>`
Remove the error from the blanket implementations `impl<T, E> Init<T, E>
for T` (and also for `PinInit`). Add impl
rust: pin-init: change blanket impls for `[Pin]Init` and add one for `Result<T, E>`
Remove the error from the blanket implementations `impl<T, E> Init<T, E>
for T` (and also for `PinInit`). Add implementations for `Result<T, E>`.
This allows one to easily construct (un)conditional failing
initializers. It also improves the compatibility with APIs that do not
use pin-init, because users can supply a `Result<T, E>` to a function
taking an `impl PinInit<T, E>`.
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Link: https://github.com/Rust-for-Linux/pin-init/pull/62/commits/58612514b256c6f4a4a0718be25298410e67387a
[ Also fix a compile error in block. - Benno ]
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/all/20250529081027.297648-2-lossin@kernel.org
[ Add title prefix `rust: pin-init`. - Benno ]
Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|