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