pm24.git, branch rust-6.6

rust: init: update expanded macro explanation

2023-08-21T12:31:49Z

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:49Z

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:49Z

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: implement `Zeroable` for `UnsafeCell` and `Opaque`

2023-08-21T12:31:49Z

`UnsafeCell` and `T` have the same layout so if `T` is `Zeroable` then so should `UnsafeCell` be. This allows using the derive macro for `Zeroable` on types that contain an `UnsafeCell`. Since `Opaque` contains a `MaybeUninit`, all bytes zero is a valid bit pattern for that type. Reviewed-by: Gary Guo Reviewed-by: Martin Rodriguez Reboredo Signed-off-by: Benno Lossin Link: https://lore.kernel.org/r/20230814084602.25699-11-benno.lossin@proton.me Signed-off-by: Miguel Ojeda

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

2023-08-21T12:31:49Z

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 functions to create array initializers

2023-08-21T12:31:49Z

Add two functions `pin_init_array_from_fn` and `init_array_from_fn` that take a function that generates initializers for `T` from `usize`, the added functions then return an initializer for `[T; N]` where every element is initialized by an element returned from the generator function. Suggested-by: Asahi Lina Reviewed-by: Björn Roy Baron Reviewed-by: Alice Ryhl Reviewed-by: Martin Rodriguez Reboredo Signed-off-by: Benno Lossin Link: https://lore.kernel.org/r/20230814084602.25699-9-benno.lossin@proton.me [ Cleaned a couple trivial nits. ] Signed-off-by: Miguel Ojeda

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

2023-08-21T12:31:48Z

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:48Z

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:48Z

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:48Z

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