Add two build_assert! lints, build_assert_not_inlined and build_assert_can_be_const

[mqqz]

Apologies for dropping a sizeable PR here with no prior heads-up; there's no expectation to review it quickly. I’m very happy to split it into smaller pieces or reorganize it in whatever way would make it easier to review.

This is my attempt at adding two (very related) lints:

• build_assert_not_inlined (from Warn on build_assert calls without #[inline(always)] #7)

warns when a build_assert! condition depends on non-static values and the surrounding function or propagated call chain is not marked #[inline(always)].

• build_assert_can_be_const (as suggested in this discussion)

warns when a build_assert! condition is already effectively constant and should use a const assert instead of build_assert!.

The implementation ended up needing a small analysis framework due to the non-local nature of the lints. Requirements can propagate through local helpers, wrappers, function pointers, and other indirect calls.

Implementation

The implementation is built around a shared build_assert! analysis pipeline rather than two unrelated lint passes. The core idea is:

1. identify build_assert! reliably

   collect explicit #[klint::diagnostic_item] annotations from source, if an item is still missing, fallback to existing out-of-band inference.

2. recover the asserted condition at the source level

   • walk macro ancestry to confirm an expression came from build_assert!
   • map that back to the source callsite of the macro invocation
   • recover the asserted condition span from the expanded HIR shape

3. classify what that condition depends on

   either Constant, Runtime or Param(FxHashset<usize>).

4. summarize that per function

   each function body is analyzed into a FunctionSummary:

   • requirement: whether non-constant values flow into build_assert!
   • return_dependency: how the function’s return value depends on inputs
   • const_only_build_asserts: source spans of constant assertions that should trigger the const lint

   we keep recomputing summaries up to a fixed-point i.e. when no other dependencies can be inferred.

5. propagate requirements through local call relationships

   I reused/refactored and extended the work done to generate a monomorphised use graph for infallible_allocation into mono_graph.rs needed to analyze calls.

   direct local calls:

   • if a local callee summary exists, map callee parameter dependencies onto caller arguments
   • only propagate dependencies for parameters that actually matter to the callee’s build_assert!

   return dependencies:

   • if a local helper returns a value that depends on parameters, callers retain that precision instead of collapsing to generic runtime

   indirect calls:

   • local function-pointer-like flows are tracked within a body
   • mono-level call graph information is used to resolve indirect and dyn-dispatch cases back to source callsites

6. emit either lint (or none) accordingly :)

Tests

UI coverage was added for both lints.

tests/ui/build_assert_not_inlined.rs tests cover:

• direct runtime-dependent assertions
• parameter + const generic mixtures
• helper calls
• caller propagation
• wrapper macros
• local rebinding
• function pointers
• mixed constant/runtime function-pointer calls
• dyn-dispatch
• partially-constant callers
• runtime-dependent match

tests/ui/build_assert_can_be_const tests cover:

• direct literal const expressions
• const generics
• wrapper macros
• local const-returning helpers
• const-only match
• comment/comma conditions
• message-form const-only assertions

Docs were also added:

• doc/build_assert_not_inlined.md
• doc/build_assert_can_be_const.md
  and README entries in the "Implemented Lints" section.

Closes: #7

[nbdd0121]

I haven't looked this in detail, but I don't think (by using mono graph & HIR) this will work across crates.

Another thing is that this looks like it's handling build_assert!() specifically, while I'd like the ability to also support

if cond {
    build_error!()
}

A more complicated case (where it actually occurs in RfL) is

if !cond { diverge!() }
build_assert!(cond);

This can happen where code first handles error path, and the second part (build_assert!) call is from inlining or macro-expansion. Even if cond refers to parameters, it does not need to actually be #[inline].

Have you run through your changes on Linux codebase, and what's the result like?

[mqqz]

I haven't looked this in detail, but I don't think (by using mono graph & HIR) this will work across crates.

That's right. I didn't actually consider cross-crate analysis, apologies.

Thinking about how to fix that, perhaps generating metadata/summaries for crates and switching to MIR for propagation might work. Would that be right approach? If you think it's worthwhile, I can give that a try and push updates.

Another thing is that this looks like it's handling build_assert!() specifically, while I'd like the ability to also support

if cond {
    build_error!()
}

This seems fairly straightforward to support, most of the work to analyse cond is already in-place.

A more complicated case (where it actually occurs in RfL) is

if !cond { diverge!() }
build_assert!(cond);

This seems trickier, since that needs some notion of a previously established dominating guard so the later build_assert! does not by itself imply an inline requirement. I think I can likely address the former directly, and possibly handle the latter in a limited way for obvious patterns, but a fully general solution would be a bigger step.

Have you run through your changes on Linux codebase, and what's the result like?

A lot of instances where build_assert_can_be_const is triggered and they all seem reasonable/valid on first glance. However, no build_assert_not_inlined instances.

Lint Output on Linux Codebase

error: this `build_assert!` does not depend on runtime values; prefer `const { assert!(...) }` instead
   --> rust/kernel/dma.rs:404:9
    |
404 | /         build_assert!(
405 | |             core::mem::size_of::<T>() > 0,
406 | |             "It doesn't make sense for the allocated type to be a ZST"
407 | |         );
    | |_________^
    |
note: this assertion is already effectively constant, so it does not need `build_assert!` to optimize away an error path
   --> rust/kernel/dma.rs:404:9
    |
404 | /         build_assert!(
405 | |             core::mem::size_of::<T>() > 0,
406 | |             "It doesn't make sense for the allocated type to be a ZST"
407 | |         );
    | |_________^
    = note: `-D klint::build-assert-can-be-const` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(klint::build_assert_can_be_const)]`

error: this `build_assert!` does not depend on runtime values; prefer `const { assert!(...) }` instead
   --> rust/kernel/i2c.rs:114:9
    |
114 | /         build_assert!(
115 | |             T::ACPI_ID_TABLE.is_some() || T::OF_ID_TABLE.is_some() || T::I2C_ID_TABLE.is_some(),
116 | |             "At least one of ACPI/OF/Legacy tables must be present when registering an i2c driver"
117 | |         );
    | |_________^
    |
note: this assertion is already effectively constant, so it does not need `build_assert!` to optimize away an error path
   --> rust/kernel/i2c.rs:114:9
    |
114 | /         build_assert!(
115 | |             T::ACPI_ID_TABLE.is_some() || T::OF_ID_TABLE.is_some() || T::I2C_ID_TABLE.is_some(),
116 | |             "At least one of ACPI/OF/Legacy tables must be present when registering an i2c driver"
117 | |         );
    | |_________^

error: this `build_assert!` does not depend on runtime values; prefer `const { assert!(...) }` instead
   --> rust/kernel/list/arc.rs:254:9
    |
254 |         build_assert!(ID != ID2);
    |         ^^^^^^^^^^^^^^^^^^^^^^^^
    |
note: this assertion is already effectively constant, so it does not need `build_assert!` to optimize away an error path
   --> rust/kernel/list/arc.rs:254:9
    |
254 |         build_assert!(ID != ID2);
    |         ^^^^^^^^^^^^^^^^^^^^^^^^

error: this `build_assert!` does not depend on runtime values; prefer `const { assert!(...) }` instead
   --> rust/kernel/sync/locked_by.rs:103:9
    |
103 | /         build_assert!(
104 | |             size_of::<Lock<U, B>>() > 0,
105 | |             "The lock type cannot be a ZST because it may be impossible to distinguish instances"
106 | |         );
    | |_________^
    |
note: this assertion is already effectively constant, so it does not need `build_assert!` to optimize away an error path
   --> rust/kernel/sync/locked_by.rs:103:9
    |
103 | /         build_assert!(
104 | |             size_of::<Lock<U, B>>() > 0,
105 | |             "The lock type cannot be a ZST because it may be impossible to distinguish instances"
106 | |         );
    | |_________^

error: this `build_assert!` does not depend on runtime values; prefer `const { assert!(...) }` instead
   --> rust/kernel/sync/locked_by.rs:129:9
    |
129 | /         build_assert!(
130 | |             size_of::<U>() > 0,
131 | |             "`U` cannot be a ZST because `owner` wouldn't be unique"
132 | |         );
    | |_________^
    |
note: this assertion is already effectively constant, so it does not need `build_assert!` to optimize away an error path
   --> rust/kernel/sync/locked_by.rs:129:9
    |
129 | /         build_assert!(
130 | |             size_of::<U>() > 0,
131 | |             "`U` cannot be a ZST because `owner` wouldn't be unique"
132 | |         );
    | |_________^

error: this `build_assert!` does not depend on runtime values; prefer `const { assert!(...) }` instead
   --> rust/kernel/sync/locked_by.rs:158:9
    |
158 | /         build_assert!(
159 | |             size_of::<U>() > 0,
160 | |             "`U` cannot be a ZST because `owner` wouldn't be unique"
161 | |         );
    | |_________^
    |
note: this assertion is already effectively constant, so it does not need `build_assert!` to optimize away an error path
   --> rust/kernel/sync/locked_by.rs:158:9
    |
158 | /         build_assert!(
159 | |             size_of::<U>() > 0,
160 | |             "`U` cannot be a ZST because `owner` wouldn't be unique"
161 | |         );
    | |_________^

error: this `build_assert!` does not depend on runtime values; prefer `const { assert!(...) }` instead
   --> rust/kernel/xarray.rs:233:9
    |
233 | /         build_assert!(
234 | |             T::FOREIGN_ALIGN >= 4,
235 | |             "pointers stored in XArray must be 4-byte aligned"
236 | |         );
    | |_________^
    |
note: this assertion is already effectively constant, so it does not need `build_assert!` to optimize away an error path
   --> rust/kernel/xarray.rs:233:9
    |
233 | /         build_assert!(
234 | |             T::FOREIGN_ALIGN >= 4,
235 | |             "pointers stored in XArray must be 4-byte aligned"
236 | |         );
    | |_________^

[ojeda]

Lint Output on Linux Codebase

This is nice, thanks! Please feel free to submit them (otherwise, we can submit them or create "good first issues" for them).

By the way, we may want to suggest const_assert! instead of const { assert! } -- I just applied Gary's patch: Rust-for-Linux/linux@59bc32d ("rust: add const_assert! macro").

[mqqz]

@ojeda Nw I'll verify the lints and send a patch

[nbdd0121]

Could you split the PR into two parts, one that adds the build_assert -> const_assert lint (I think a good name for the lint is build_assert_hierarchy (which we can augment to add lint that suggests static_assert too). That lint only requires syntactical analysis and can be complete local.

The build_assert_not_inlined lint would need some additional work, and probably a careful thoughts/discussion about what to do and how to do, and would more time/iterations.

[ojeda]

By the way, we may want to suggest const_assert! instead of const { assert! } -- I just applied Gary's patch: Rust-for-Linux/linux@59bc32d ("rust: add const_assert! macro").

@ojeda Nw I'll verify the lints and send a patch

Thanks for sending it! I mentioned Klint and this PR in the maling list :)

https://lore.kernel.org/rust-for-linux/20260330020234.16893-1-mo@sdhn.cc/