linux-toradex.git/rust/kernel/init, branch v6.9-rc5

rust: init: update expanded macro explanation

2023-08-21T12:31:49+00:00

The previous patches changed the internals of the macros resulting in
the example expanded code being outdated. This patch updates the example
and only changes documentation.

Reviewed-by: Martin Rodriguez Reboredo 
Signed-off-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230814084602.25699-14-benno.lossin@proton.me
Reviewed-by: Alice Ryhl 
Signed-off-by: Miguel Ojeda

rust: init: add `{pin_}chain` functions to `{Pin}Init`

2023-08-21T12:31:49+00:00

The `{pin_}chain` functions extend an initializer: it not only
initializes the value, but also executes a closure taking a reference to
the initialized value. This allows to do something with a value directly
after initialization.

Suggested-by: Asahi Lina 
Reviewed-by: Martin Rodriguez Reboredo 
Signed-off-by: Benno Lossin 
Reviewed-by: Alice Ryhl 
Link: https://lore.kernel.org/r/20230814084602.25699-13-benno.lossin@proton.me
[ Cleaned a few trivial nits. ]
Signed-off-by: Miguel Ojeda

rust: init: make `PinInit` a supertrait of `Init`

2023-08-21T12:31:49+00:00

Remove the blanket implementation of `PinInit for I where I:
Init`. This blanket implementation prevented custom types that
implement `PinInit`.

Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Alice Ryhl 
Reviewed-by: Gary Guo 
Signed-off-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230814084602.25699-12-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda

rust: init: add support for arbitrary paths in init macros

2023-08-21T12:31:49+00:00

Previously only `ident` and generic types were supported in the
`{try_}{pin_}init!` macros. This patch allows arbitrary path fragments,
so for example `Foo::Bar` but also very complex paths such as
`::Bar::<0, i32>`.

Internally this is accomplished by using `path` fragments. Due to some
peculiar declarative macro limitations, we have to "forget" certain
additional parsing information in the token trees. This is achieved by
using the `paste!` proc macro. It does not actually modify the input,
since no `[< >]` will be present in the input, so it just strips the
information held by declarative macros. For example, if a declarative
macro takes `$t:path` as its input, it cannot sensibly propagate this to
a macro that takes `$($p:tt)*` as its input, since the `$t` token will
only be considered one `tt` token for the second macro. If we first pipe
the tokens through `paste!`, then it parses as expected.

Suggested-by: Asahi Lina 
Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Alice Ryhl 
Reviewed-by: Gary Guo 
Signed-off-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230814084602.25699-10-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda

rust: init: add `..Zeroable::zeroed()` syntax for zeroing all missing fields

2023-08-21T12:31:48+00:00

Add the struct update syntax to the init macros, but only for
`..Zeroable::zeroed()`. Adding this at the end of the struct initializer
allows one to omit fields from the initializer, these fields will be
initialized with 0x00 set to every byte. Only types that implement the
`Zeroable` trait can utilize this.

Suggested-by: Asahi Lina 
Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Alice Ryhl 
Reviewed-by: Gary Guo 
Signed-off-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230814084602.25699-8-benno.lossin@proton.me
[ Rebased on `rust-next` and cleaned a few trivial nits. ]
Signed-off-by: Miguel Ojeda

rust: init: make initializer values inaccessible after initializing

2023-08-21T12:31:48+00:00

Previously the init macros would create a local variable with the name
and hygiene of the field that is being initialized to store the value of
the field. This would override any user defined variables. For example:
```
struct Foo {
    a: usize,
    b: usize,
}
let a = 10;
let foo = init!(Foo{
    a: a + 1, // This creates a local variable named `a`.
    b: a, // This refers to that variable!
});
let foo = Box::init!(foo)?;
assert_eq!(foo.a, 11);
assert_eq!(foo.b, 11);
```

This patch changes this behavior, so the above code would panic at the
last assertion, since `b` would have value 10.

Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Alice Ryhl 
Reviewed-by: Gary Guo 
Signed-off-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230814084602.25699-7-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda

rust: init: wrap type checking struct initializers in a closure

2023-08-21T12:31:48+00:00

In the implementation of the init macros there is a `if false` statement
that type checks the initializer to ensure every field is initialized.
Since the next patch has a stack variable to store the struct, the
function might allocate too much memory on debug builds. Putting the
struct into a closure that is never executed ensures that even in debug
builds no stack overflow error is caused. In release builds this was not
a problem since the code was optimized away due to the `if false`.

Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Alice Ryhl 
Reviewed-by: Gary Guo 
Signed-off-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230814084602.25699-6-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda

rust: init: make guards in the init macros hygienic

2023-08-21T12:31:48+00:00

Use hygienic identifiers for the guards instead of the field names. This
makes the init macros feel more like normal struct initializers, since
assigning identifiers with the name of a field does not create
conflicts.

Also change the internals of the guards, no need to make the `forget`
function `unsafe`, since users cannot access the guards anyways. Now the
guards are carried directly on the stack and have no extra `Cell`
field that marks if they have been forgotten or not, instead they are
just forgotten via `mem::forget`.

Suggested-by: Asahi Lina 
Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Alice Ryhl 
Reviewed-by: Gary Guo 
Signed-off-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230814084602.25699-5-benno.lossin@proton.me
[ Cleaned a few trivial nits. ]
Signed-off-by: Miguel Ojeda

rust: add derive macro for `Zeroable`

2023-08-21T12:31:48+00:00

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

rust: init: make `#[pin_data]` compatible with conditional compilation of fields

2023-08-21T12:31:48+00:00

This patch allows one to write
```
#[pin_data]
pub struct Foo {
    #[cfg(CONFIG_BAR)]
    a: Bar,
    #[cfg(not(CONFIG_BAR))]
    a: Baz,
}
```
Before, this would result in a compile error, because `#[pin_data]`
would generate two functions named `a` for both fields unconditionally.

Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Gary Guo 
Reviewed-by: Alice Ryhl 
Signed-off-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230814084602.25699-3-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda