Re: [PATCH v3 4/4] rust: make `build_assert` module the home of related macros

["Gary Guo" <gary@garyguo.net>]

On Sat Mar 21, 2026 at 1:05 PM GMT, Alexandre Courbot wrote:
> On Thu Mar 19, 2026 at 9:16 PM JST, Gary Guo wrote:
>> From: Gary Guo <gary@garyguo.net>
>>
>> Given the macro scoping rules, all macros are rendered 3 times, in the
>> module, in the top-level of kernel crate, and in the prelude.
>>
>> Add `#[doc(no_inline)]` to the prelude so it just shows up as re-export.
>> Add `#[doc(hidden)]` to the macro definition and `#[doc(inline)]` to the
>> re-export inside `build_assert` module so the top-level items are hidden.
>>
>> Signed-off-by: Gary Guo <gary@garyguo.net>
>> ---
>>  drivers/gpu/nova-core/bitfield.rs    |  4 ++--
>>  drivers/gpu/nova-core/num.rs         |  2 +-
>>  rust/kernel/build_assert.rs          | 19 ++++++++++++-------
>>  rust/kernel/dma.rs                   |  5 +++--
>>  rust/kernel/io/register.rs           | 19 ++++++++++++-------
>>  rust/kernel/io/resource.rs           |  2 +-
>>  rust/kernel/ioctl.rs                 |  2 +-
>>  rust/kernel/net/phy/reg.rs           |  8 +++++---
>>  rust/kernel/num/bounded.rs           |  2 +-
>>  rust/kernel/prelude.rs               |  3 ++-
>>  rust/kernel/sync/atomic/internal.rs  |  9 ++++++---
>>  rust/kernel/sync/atomic/predefine.rs |  2 +-
>>  rust/kernel/sync/locked_by.rs        |  2 +-
>>  rust/kernel/sync/refcount.rs         |  8 +++++---
>>  rust/kernel/xarray.rs                | 10 ++++++++--
>>  15 files changed, 61 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/gpu/nova-core/bitfield.rs b/drivers/gpu/nova-core/bitfield.rs
>> index 16e143658c51..c3e1235ad7fb 100644
>> --- a/drivers/gpu/nova-core/bitfield.rs
>> +++ b/drivers/gpu/nova-core/bitfield.rs
>> @@ -170,7 +170,7 @@ impl $name {
>>      (@check_field_bounds $hi:tt:$lo:tt $field:ident as bool) => {
>>          #[allow(clippy::eq_op)]
>>          const _: () = {
>> -            ::kernel::build_assert!(
>> +            ::kernel::build_assert::build_assert!(
>
> Given that the `build_assert` module now hosts 3 different assert
> macros, have we considered renaming it to just `assert`? Otherwise the
> naming implies that it is more connected to the `build_assert` macro
> than the others, which doesn't seem to be true.

I personally view them all as variants of BUILD_BUG_ON, hence the name is
`build_assert`. I thought about `assert`, but to me that feels like it's going
to host runtime assertions.

I won't be surprised if we're going to have `assert` module in the future to
host families of

    assert!()
    warn_on!()
    unsafe { assume!() }
    ensure!()

etc..

Best,
Gary