Re: [PATCH 1/2] rust: num: casts: replace const type narrowing methods with a macro

["Alexandre Courbot" <acourbot@nvidia.com>]

On Tue Aug 25, 2026 at 11:39 PM JST, Gary Guo wrote:
> On Tue Aug 25, 2026 at 3:26 PM BST, Alexandre Courbot wrote:
>> On Tue Aug 25, 2026 at 9:01 PM JST, Gary Guo wrote:
>>> On Tue Aug 25, 2026 at 9:25 AM BST, Miguel Ojeda wrote:
>>>> What I wouldn't want is a raw `as`, because the point of the saga we
>>>> started a long time ago is to introduce better tools that allow us to
>>>> get rid of the almighty `as` into weaker (i.e. safer) options, even if
>>>> some uses of `as` may be "obviously right".
>>>
>>> I think that is rather a linting issue, not something that warrants extra code
>>> in kernel. We have been requesting some extra clippy features and I think that
>>> is the correct way to go, not add a ton of methods and macros. Yes, it wasn't
>>> moving on clippy end, but I could add a feature to klint instead?
>>>
>>> Do you think we still need all these extra function and macros if we
>>> can get clippy (or klint) to enforce CAST comments?
>>>
>>> I can imagine the following rules that would practically solve all the footgun
>>> of `as` numerical casts without having to use awkward syntax:
>>>
>>> * widening casts are allowed
>>> * narrowing casts is disallowed unless CAST comment exists, except where its
>>>   value is constant and truncation does not happen.
>>
>> These rules classify casts by width, but the footguns really are about
>> which values are actually being converted.
>>
>> In particular for value narrowing we still end up with CAST comments,
>> whose existence a lint can check, but not their correctness (for
>> instance, a bindgen-provided constant that changes in a breaking way).
>> `const_as!` lets us drop them altogether.
>
> The rule says "except where its value is constant and truncation does not
> happen".
>
> So I'd imagine just writing
>
>     bindings::FOO as u32
>
> and *NOT* have CAST comment, and a warning being generated if truncation
> happens.

I can see a use for a lint that warns about `as` expressions without a
CAST comment, yes. But the warning should be unconditional imho -
otherwise an `as` without a CAST comment could be intended as
non-truncating, or it could just be an omission from the author of the
code, and there is no good way to tell.

`const_as!` basically provides everything we need to document intent and
verify the behavior of non-truncating casts, and I think it is useful to
keep as much as possible at the compiler level. KLint is not part of a
regular build, and enabling it involves some effort that not everybody
will go through. `const_as!` emits an error exactly when we need it to,
without any extra tool, and is both simple in its implementation and its
use.

I am also not sure whether KLint could cover something like this, that
requires post-monomorphization analysis:

    fn f<const N: usize>() -> u16 {
        N as u16
    }

Generally speaking, I believe a sane policy is to delegate tasks to the
lowest layer that can do the job. Here the compiler is clearly capable.