Re: [PATCH v2 1/7] rust: build_assert: add instructions for use with function arguments

[John Hubbard <jhubbard@nvidia.com>]

On 11/30/25 2:42 PM, Miguel Ojeda wrote:
> On Sun, Nov 30, 2025 at 11:01 PM John Hubbard <jhubbard@nvidia.com> wrote:
>>
>> It seems pretty clear that if one writes a *build* assertion about
>> a function argument, then that is just conceptually wrong unless it
>> is inlined. Because it can only really be a run-time assertion.
>>
>> This is what Alex pointed out, and looking at the code I agree.
> 
> No, the function here was already inline.

More precisely, it was already *hinted* to be inline.

> 
> What Alexandre wrote, which is correct, is that the fix is about
> asking for *more* inlining.
> 
> The build assertion itself is fine. What is "wrong" is that the
> inlining wasn't enough.

I'm having a difficult time with that statement, because if you
write:

fn bar(n: usize) {
    build_assert!(n > 1);
    ...
}

Then that is conceptually wrong, because it must be a runtime check.

The only way it can be a compile-time check is if you have some
way to *guarantee* that the function is inlined into code that has
a const n.

Absent such guarantees (and we have "nearly none", right?), we have
been writing "partly wrong" code in all such cases.

Why? Are the guarantees stronger than they look? Or other reasoning?

> 
> Nevertheless, it is (or at least some of these are) definitely a "fix"
> in the sense that it did fix cases we hit where the inlining wasn't
> enough, like Clippy ones which may change codegen (which in turn is
> why we say it cannot be used in "production" kernel builds:
> https://github.com/rust-lang/rust-clippy/pull/8037 -- back then it
> disabled MIR optimizations).
> 

Sorry for the fussy detailed questioning here. I'm trying to bottom
out here because CLIPPY=1 is a very solid requirement before posting
patches. 


thanks,
-- 
John Hubbard