kernel/rust/macros/zeroable.rs, branch linux-rolling-stable

rust: move pin-init API into its own directory

2025-03-16T20:59:18Z

In preparation of splitting off the pin-init crate from the kernel crate, move all pin-init API code (including proc-macros) into `rust/pin-init`. Moved modules have their import path adjusted via the `#[path = "..."]` attribute. This allows the files to still be imported in the kernel crate even though the files are in different directories. Code that is moved out of files (but the file itself stays where it is) is imported via the `include!` macro. This also allows the code to be moved while still being part of the kernel crate. Note that this commit moves the generics parsing code out of the GPL-2.0 file `rust/macros/helpers.rs` into the Apache-2.0 OR MIT file `rust/pin_init/internal/src/helpers.rs`. I am the sole author of that code and it already is available with that license at [1]. The same is true for the entry-points of the proc-macros `pin_data`, `pinned_drop` and `derive_zeroable` in `rust/macros/lib.rs` that are moved to `rust/pin_data/internal/src/lib.rs`. Although there are some smaller patches that fix the doctests. Link: https://github.com/Rust-for-Linux/pinned-init [1] Signed-off-by: Benno Lossin Reviewed-by: Andreas Hindborg Reviewed-by: Fiona Behrens Tested-by: Andreas Hindborg Link: https://lore.kernel.org/r/20250308110339.2997091-3-benno.lossin@proton.me Signed-off-by: Miguel Ojeda

rust: macros: add `decl_generics` to `parse_generics()`

2024-04-07T20:03:42Z

The generic parameters on a type definition can specify default values. Currently `parse_generics()` cannot handle this though. For example when parsing the following generics: The `impl_generics` will be set to `T: Clone, const N: usize = 0` and `ty_generics` will be set to `T, N`. Now using the `impl_generics` on an impl block: impl<$($impl_generics)*> Foo {} will result in invalid Rust code, because default values are only available on type definitions. Therefore add parsing support for generic parameter default values using a new kind of generics called `decl_generics` and change the old behavior of `impl_generics` to not contain the generic parameter default values. Now `Generics` has three fields: - `impl_generics`: the generics with bounds (e.g. `T: Clone, const N: usize`) - `decl_generics`: the generics with bounds and default values (e.g. `T: Clone, const N: usize = 0`) - `ty_generics`: contains the generics without bounds and without default values (e.g. `T, N`) `impl_generics` is designed to be used on `impl<$impl_generics>`, `decl_generics` for the type definition, so `struct Foo<$decl_generics>` and `ty_generics` whenever you use the type, so `Foo<$ty_generics>`. Here is an example that uses all three different types of generics: let (Generics { decl_generics, impl_generics, ty_generics }, rest) = parse_generics(input); quote! { struct Foo<$($decl_generics)*> { // ... } impl<$impl_generics> Foo<$ty_generics> { fn foo() { // ... } } } The next commit contains a fix to the `#[pin_data]` macro making it compatible with generic parameter default values by relying on this new behavior. Signed-off-by: Benno Lossin Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20240309155243.482334-1-benno.lossin@proton.me Signed-off-by: Miguel Ojeda

rust: add derive macro for `Zeroable`

2023-08-21T12:31:48Z

Add a derive proc-macro for the `Zeroable` trait. The macro supports structs where every field implements the `Zeroable` trait. This way `unsafe` implementations can be avoided. The macro is split into two parts: - a proc-macro to parse generics into impl and ty generics, - a declarative macro that expands to the impl block. Suggested-by: Asahi Lina Signed-off-by: Benno Lossin Reviewed-by: Gary Guo Reviewed-by: Martin Rodriguez Reboredo Link: https://lore.kernel.org/r/20230814084602.25699-4-benno.lossin@proton.me [ Added `ignore` to the `lib.rs` example and cleaned trivial nit. ] Signed-off-by: Miguel Ojeda