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

"Alexandre Courbot" <[email protected]>
Newsgroups dev.linux.lists.nova-gpu,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.