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

["Gary Guo" <gary@garyguo.net>]

On Wed Aug 26, 2026 at 12:00 PM BST, Alexandre Courbot wrote:
> 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.

I think a "no comment means no truncation is going to happen" enforced by
linter is the point? I'd use "unsafe" as the parallel analogy. You don't see if
a function is unsafe or not, you use the absence of "unsafe" block as a
guarantee that there's no unsafe code within a block.

>
> `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.

Enabling it is quite easy actually, just that it is more involved to package if
one is not using rustup nor nix. Once it's installed the only thing needed is a
RUSTC=klint in make command line.

The bare installation does not however allow you to name the lints so everything
is at the default level and you cannot suppress it. The required feature
`register_tool` is being worked on and I intend to upstream klint support some
time this year.

Also, as long as we have CI systems to do a build, I think it's not necessary
for everyone to run it themselves.

>
> 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
>     }

So for clippy (and likely klint if it implements the feature), it would be done
pre-mono so it would require a CAST comment without checking.

>
> 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.

That's why I want to get the task done by clippy/klint instead. Because it *is*
the compiler, which is lower layer than a macro.

Best,
Gary