Re: [PATCH 2/2] rust: add `const_assert!` macro

[Yury Norov]

On Fri, Feb 06, 2026 at 09:48:59PM +0000, Gary Guo wrote:
> On Fri Feb 6, 2026 at 9:30 PM GMT, Benno Lossin wrote:
> > On Fri Feb 6, 2026 at 6:12 PM CET, Gary Guo wrote:
> >> +/// Assertion during constant evaluation.
> >> +///
> >> +/// This is a more powerful version of `static_assert` that can refer to generics inside functions
> >> +/// or implementation blocks. However, it also have a limitation where it can only appear in places
> >> +/// where statements can appear; for example, you cannot use it as an item in the module.
> >> +///
> >> +/// [`static_assert!`] should be preferred where possible.

This is confusing. You begin with "const_assert!() is more powerful",
and finally recommend to use a less powerful option.

> >> +///
> >> +/// # Examples
> >> +///
> >> +/// When the condition refers to generic parameters [`static_assert!`] cannot be used.
> >> +/// Use `const_assert!` in this scenario.
> >> +/// ```
> >> +/// fn foo<const N: usize>() {
> >> +///     // `static_assert!(N > 1);` is not allowed
> >> +///     const_assert!(N > 1); // Compile-time check
> >> +///     build_assert!(N > 1); // Build-time check
> >
> > I think having "Build-time check" here is a bit confusing, how about we
> > change it to "Link-time check"? Since a "Compile-time check" also is
> > done at "Build-time"
> 
> This is the intentional phrasing that I used for `build_assert!` when I created
> it, for the reason that `build_assert!` ensure that it will fire, at latest,
> link time. However, if you actually use such methods with CTFE, it will error
> earlier. So it is "at latest link-time check", so I decided to just use
> "build-time".

I don't think this compiler implementation details should sneak into
the kernel. The compiler may get changed, or whatever else, and this
all will become just non-relevant.

So, can you once more explain when static_assert!() is preferable over
const_assert!() over build_assert!(); strictly from a users' perspective?

On the C side we've got similar statically_true() and const_true()
macros, but they seemingly have a different meaning:

  /*
   * Useful shorthand for "is this condition known at compile-time?"
   *
   * Note that the condition may involve non-constant values,
   * but the compiler may know enough about the details of the
   * values to determine that the condition is statically true.
   */
  #define statically_true(x) (__builtin_constant_p(x) && (x))
  
  /*
   * Similar to statically_true() but produces a constant expression
   *
   * To be used in conjunction with macros, such as BUILD_BUG_ON_ZERO(),
   * which require their input to be a constant expression and for which
   * statically_true() would otherwise fail.
   *
   * This is a trade-off: const_true() requires all its operands to be
   * compile time constants. Else, it would always returns false even on
   * the most trivial cases like:
   *
   *   true || non_const_var
   *
   * On the opposite, statically_true() is able to fold more complex
   * tautologies and will return true on expressions such as:
   *
   *   !(non_const_var * 8 % 4)
   *
   * For the general case, statically_true() is better.
   */
  #define const_true(x) __builtin_choose_expr(__is_constexpr(x), x, false)

Is it possible to maintain consistency with C on rust side? If not,
can you take those C comments as the reference for what level of
detalization is desired? Maybe pick different names then?

Thanks,
Yury