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

[Yury Norov <ynorov@nvidia.com>]

On Sun, Feb 08, 2026 at 11:35:51AM +0100, Miguel Ojeda wrote:
> On Sun, Feb 8, 2026 at 6:58 AM Yury Norov <ynorov@nvidia.com> wrote:
> >
> > This is confusing. You begin with "const_assert!() is more powerful",
> > and finally recommend to use a less powerful option.
> 
> The goal is that users use the least powerful one that applies, not
> the other way around, because the least powerful ones fail earlier and
> are generally more robust.
> 
> I think the first example is intended to show the different ones, but
> I think the wording can be improved -- the one in the existing
> `build_assert!` docs is a bit clearer.

Can you please keep more context? It would be easier to refer to an
example if I have it on hand.
 
> Gary: perhaps we could factor out the explanation/examples to the
> module-level docs, and then link to it from all the three asserts.
> 
> > 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.
> 
> How do they sneak into the kernel? Gary is explaining why it is not
> called "link time", precisely because that would expose more details,
> not less.
> 
> Regardless, that "link-time" vs. "build-time" discussion is
> independent of this patch, because those docs already exist in the
> tree.

Again, more context would help. So this is the original comment from
Benno, and Gary's reply:

  > 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 agree with ""Build-time check" here is a bit confusing", and the
following indeed looks like a compiler implementation discussion. So
I concluded that the difference between build_assert and const_assert
is not visible from programmer's POV. Please correct me if I'm wrong.

> > On the C side we've got similar statically_true() and const_true()
> > macros, but they seemingly have a different meaning:
> 
> > 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?
> 
> Please explain what inconsistency you are seeing here.

OK, maybe it's just me, but this is how I build a map between rust and C:

 - Plain BUG_ON() matches plain assert!();
 - BUILD_BUG_ON() is compiletime_assert() and matches build_assert!();
 - BUILD_BUG_ON_ZERO() - same as BUILD_BUG_ON(), but can be used in
   initialization constructions, like GENMASK(), i.e. rvalue. No direct
   analogue in Rust;
 - BUILD_BUG_ON(statically_true()) - allows runtime conditions, like
   "true || runtime_cond", and matches static_assert!() in rust;
 - BUILD_BUG_ON(const_true()) - doesn't allow runtime conditions.

I expected that const_assert!() would be an analogue for
BUILD_BUG_ON(const_true()), but it is seemingly a different thing. Or
am I wrong?
 
> Also, please note that two of the three names have been for years in
> the kernel tree, and that standard C also uses `static_assert` as a
> name. `const_assert` fits the pattern and it literally expands to what
> it says.
> 
> Moreover, `const` in C is not the same as `const` in Rust. `constexpr`
> in C is closer to `const` in Rust.
> 
> By the way, I am not sure why you suggested `const_true` for the name
> of that C macro -- I think it should be `constexpr_true` instead,
> which is closer to what it does, and it fits the pattern on the C side
> better, too. So that would be more consistent.

I suggested const_true() over the original underscored _statically_true(),
and this is an obvious improvement. If you think that 'constexpr_true()'
would add to explainability, please submit a patch. I have a weakly
negative opinion on that.

Thanks,
Yury