Re: [PATCH] rust: bitfield: require Zeroable storage for Zeroable impl

["Alexandre Courbot" <acourbot@nvidia.com>]

On Mon Sep 21, 2026 at 7:05 PM JST, Gary Guo wrote:
> On Mon Sep 21, 2026 at 8:18 AM BST, Alexandre Courbot wrote:
>> On Mon Sep 21, 2026 at 3:32 PM JST, Yilin Chen wrote:
>>> Hi Gary,
>>>
>>> Resending my reply for visibility on the mailing list.
>>>
>>> You are right that a bitfield with at least one field generates a use of
>>> `Bounded<$storage, ...>`, which requires the storage type to implement
>>> `Integer`. However, `bitfield!` also accepts an empty field list. In that
>>> case, no `Bounded` use is generated, so the `Integer` requirement is
>>> absent, while the macro still generates the unconditional `Zeroable`
>>> implementation.
>>>
>>> For example:
>>>
>>>     use core::num::NonZeroU32;
>>>     use pin_init::Zeroable;
>>>
>>>     bitfield! {
>>>         struct Bad(NonZeroU32) {}
>>>     }
>>>
>>>     fn check_bad_zeroable() {
>>>         let _: Bad = <Bad as Zeroable>::zeroed();
>>>     }
>>>
>>> This currently compiles.
>>
>> No it doesn't.
>>
>> error[E0277]: the trait bound `core::num::NonZero<u32>: kernel::mem::AsRepr` is not satisfied
>> 364 | /         bitfield! {
>> 365 | |             struct Bad(NonZeroU32) {}
>> 366 | |         }
>>     | |_________^ the trait `kernel::mem::AsRepr` is not implemented for `core::num::NonZero<u32>`
>
> On the other hand, it makes sense for `NonZero<u32>` to implement
> `AsRepr<Repr = u32>`. So I think we do need better defense.
>
> Given that fundamental `bitfield!` needs a plain integer type, I don't think we
> want a `Zeroable` bound, but rather just enforce it has to be integer
> primitives.
>
> Given the recent `Integer` sealing, ad a check that $storage implements
> `Integer` is probably the best check.

That, or we only derive `Zeroable` on a bitfield if its storage type
also implements `Zeroable`.

... but that possibly leaves other ways in which the invariant for
`NonZero` would not be enforced, and I don't see the point for a
bitfield to be backed by anything but a primitive type, so maybe
limiting storage to implementors of `Integer` is the right move indeed.

Yilin, do you want to send a patch for this?