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

[Alexandre Courbot]

On Thu Mar 19, 2026 at 9:16 PM JST, Gary Guo wrote:
> From: Gary Guo <gary@xxxxxxxxxxx>
>
> 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@xxxxxxxxxxx>
> ---
>  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.