From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Eliot Courtney" <ecourtney@nvidia.com>
Cc: "Yury Norov" <yury.norov@gmail.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Tamir Duberstein" <tamird@kernel.org>,
"Onur Özkan" <work@onurozkan.dev>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>, "Zhi Wang" <zhiw@nvidia.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
nova-gpu@lists.linux.dev
Subject: Re: [PATCH 1/2] rust: num: casts: replace const type narrowing methods with a macro
Date: Wed, 26 Aug 2026 22:27:33 +0900 [thread overview]
Message-ID: <DKYWSC1VZHDJ.1H8PTHTJ0NM8X@nvidia.com> (raw)
In-Reply-To: <DKYTZNAX6ON6.1K1372FFAQOF7@nvidia.com>
On Wed Aug 26, 2026 at 8:16 PM JST, Alexandre Courbot wrote:
> On Tue Aug 25, 2026 at 4:18 PM JST, Eliot Courtney wrote:
>> On Tue Aug 25, 2026 at 11:44 AM JST, Alexandre Courbot wrote:
>>> The casts module features a series of const converters (e.g.
>>> `u32_into_u16`) that narrow the type of a const expression provided that
>>> its value can be proven to fit into the destination type at
>>> compile-time.
>>>
>>> These functions are numerous (9 of them), generated by a macro and thus
>>> not easily discoverable, and cumbersome to use as they require a
>>> turbofish and const expression between `{` and `}` braces.
>>>
>>> Replace them all by a single `const_as!` macro that expands to a const
>>> block verifying the lossless nature of the conversion at compile-time.
>>> This turns e.g.:
>>>
>>> const DMA_LEN: u32 = casts::usize_into_u32::<{ MEM_BLOCK_ALIGNMENT }>();
>>>
>>> into
>>>
>>> const DMA_LEN: u32 = casts::const_as!(MEM_BLOCK_ALIGNMENT => u32);
>>>
>>> This makes things easier to read and understand, while shifting the
>>> burden of checking the conversion's validity from reviewers (via a CAST
>>> comment) to the compiler.
>>>
>>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>>> ---
>>> rust/kernel/num/casts.rs | 129 +++++++++++++++++++++++++++++------------------
>>> 1 file changed, 79 insertions(+), 50 deletions(-)
>>>
>>> diff --git a/rust/kernel/num/casts.rs b/rust/kernel/num/casts.rs
>>> index 7e6c7dec747d..a4a18a6f2ba8 100644
>>> --- a/rust/kernel/num/casts.rs
>>> +++ b/rust/kernel/num/casts.rs
>>> @@ -20,10 +20,8 @@
>>> //! - Two extension traits, [`FromSafeCast`] and [`IntoSafeCast`], providing conversion methods
>>> //! similar to [`From`] and [`Into`] for conversions that are safe to perform in the kernel, but
>>> //! not supported by the standard library.
>>> -//! - Another series of const functions (e.g. [`u64_into_u8`]) supporting the conversion of a const
>>> -//! value from a larger type into a smaller one, provided the value fits into the destination
>>> -//! type. This is useful if a constant is defined as a larger type, but needs to be used as a
>>> -//! smaller one.
>>> +//! - A [`const_as!`] macro, losslessly casting a constant expression between any two integer
>>> +//! types, with conversions that would alter the value reported as build errors.
>>> //! - An [`arch`] sub-module, defining more conversion functions that are only guaranteed to be
>>> //! lossless for a given pointer size. These can only be used in code that is specific to a
>>> //! given pointer size.
>>
>> Can we add guidance somewhere in this file on when to use const_as! vs
>> when to use the u8_as_usize etc ones, when both could work? e.g. use
>> const_as! if you can, otherwise use the function version, or, use the
>> function version if it's sufficient (types alone are enough to prove)
>> otherwise use the macro.
>
> Yes, that's a very good idea and the use we are currently doing in Nova
> is also not consistent. Basically I think that the priority should be,
> in order of preference:
>
> - stdlib's `From`,
> - `FromSafeCast`/`IntoSafeCast` (for non-const contexts)
> - `const_as!` (for constant expressions including narrowing)
> - `*_as_*` (for const fns with a runtime value)
>
>>
>> [...]
>>> +#[macro_export]
>>> +#[doc(hidden)]
>>> +macro_rules! const_as {
>>> + ($v:expr => $into:ty) => {
>>> + const {
>>> + #[allow(unused_comparisons, unused_assignments, clippy::as_underscore)]
>>> + {
>>> + let v = $v;
>>> + let r = v as $into;
>>> + // Pin `back` to `v`'s type so `as _` casts back to the source type.
>>> + let mut back = v;
>>> + back = r as _;
>>>
>>> - N as $into
>>> + ::core::assert!(
>>> + back == v && (v < 0) == (r < 0),
>>> + "value does not fit into the target type"
>>> + );
>>
>> What about giving some text on what doesn't fit where? e.g.
>> ::core::concat!("`", ::core::stringify!($v), "` does not fit into `", ::core::stringify!($into), "`")
>
> Will do.
... actually, that's probably not needed. Compiler diagnostics already
print the faulting line verbatim, so the expression is fully visible.
Stringifying it would just duplicate information that sits on the very
next line.
next prev parent reply other threads:[~2026-08-26 13:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 2:44 [PATCH 0/2] rust: num: casts: replace const type narrowing methods with a macro Alexandre Courbot
2026-08-25 2:44 ` [PATCH 1/2] " Alexandre Courbot
2026-08-25 7:18 ` Eliot Courtney
2026-08-26 11:16 ` Alexandre Courbot
2026-08-26 13:27 ` Alexandre Courbot [this message]
2026-08-25 8:25 ` Miguel Ojeda
2026-08-25 12:01 ` Gary Guo
2026-08-25 14:26 ` Alexandre Courbot
2026-08-25 14:39 ` Gary Guo
2026-08-26 11:00 ` Alexandre Courbot
2026-08-26 12:06 ` Gary Guo
2026-08-25 13:54 ` Alexandre Courbot
2026-08-25 14:02 ` Danilo Krummrich
2026-08-25 14:11 ` Gary Guo
2026-08-25 14:30 ` Alexandre Courbot
2026-08-25 12:04 ` Gary Guo
2026-08-25 2:44 ` [PATCH 2/2] gpu: nova-core: use kernel lossless integer conversion module Alexandre Courbot
2026-08-25 5:27 ` Eliot Courtney
2026-08-27 1:36 ` Alexandre Courbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DKYWSC1VZHDJ.1H8PTHTJ0NM8X@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=work@onurozkan.dev \
--cc=yury.norov@gmail.com \
--cc=zhiw@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox