Re: [PATCH 4/7] rust: init: wrap type checking struct initializers in a closure
From: Benno Lossin
Date: Sat Jun 24 2023 - 17:06:14 EST
On 6/24/23 17:03, Björn Roy Baron wrote:
> On Saturday, June 24th, 2023 at 11:25, Benno Lossin <benno.lossin@xxxxxxxxx> wrote:
>
>> 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 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`.
>>
>> Signed-off-by: Benno Lossin <benno.lossin@xxxxxxxxx>
>> ---
>> rust/kernel/init/macros.rs | 18 +++++++++++-------
>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/rust/kernel/init/macros.rs b/rust/kernel/init/macros.rs
>> index df4281743175..1e0c4aca055a 100644
>> --- a/rust/kernel/init/macros.rs
>> +++ b/rust/kernel/init/macros.rs
>> @@ -1037,14 +1037,18 @@ macro_rules! __init_internal {
>> // We use unreachable code to ensure that all fields have been mentioned exactly
>> // once, this struct initializer will still be type-checked and complain with a
>> // very natural error message if a field is forgotten/mentioned more than once.
>> - #[allow(unreachable_code, clippy::diverging_sub_expression)]
>> + #[allow(unreachable_code,
>> + clippy::diverging_sub_expression,
>> + clippy::redundant_closure_call)]
>> if false {
>> - $crate::__init_internal!(make_initializer:
>> - @slot(slot),
>> - @type_name($t),
>> - @munch_fields($($fields)*,),
>> - @acc(),
>> - );
>> + (|| {
>> + $crate::__init_internal!(make_initializer:
>> + @slot(slot),
>> + @type_name($t),
>> + @munch_fields($($fields)*,),
>> + @acc(),
>> + );
>> + })();
>
> Is it necessary to call this closure? Typechecking of the closure should happen even without calling it.
You are right, I do not need to call it. Will fix.
--
Cheers,
Benno
>
>> }
>> }
>> Ok(__InitOk)
>> --
>> 2.41.0
>
> Cheers,
> Björn