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:

quoted

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