Re: linux-next: build failure after merge of the rust tree

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

On Tue Jun 24, 2025 at 9:16 PM JST, Tamir Duberstein wrote:
> On Tue, Jun 24, 2025 at 5:14 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>> On Tue Jun 24, 2025 at 9:00 PM JST, Danilo Krummrich wrote:
>> > On Tue, Jun 24, 2025 at 12:31:52PM +0200, Miguel Ojeda wrote:
>> >> On Tue, Jun 24, 2025 at 9:31 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >> >
>> >> > error[E0277]: the trait bound `u32: From<DmaTrfCmdSize>` is not satisfied
>> >>
>> >> > error[E0599]: no method named `as_nanos` found for struct `Delta` in the current scope
>> >>
>> >> > Presumably caused by commit
>> >> >
>> >> >   b7c8d7a8d251 ("rust: enable `clippy::cast_lossless` lint")
>> >>
>> >> The first error, yes -- the `register!` macro was changed to use
>> >> `u32::from()` to avoid an `as` cast in that commit, and while the cast
>> >> is OK converting the new `enum`s like `FalconCoreRev`, `from()`
>> >> isn't`, so we would need to implement `From` explicitly -- Cc'ing
>> >> Danilo, Alexandre, Lyude.
>> >
>> > It's a bit annoying to implement From explicitly for all of them, but it seems
>> > to be the correct thing to do.
>>
>> This might be something `FromPrimitive` will help with eventually, but
>> in the meantime I agree having explicit implementations is a bit
>> cumbersome.
>>
>> What I don't understand is why these `as` are problematic - a type like
>> `FalconCoreRev` is `repr(u8)`, so the cast cannot be lossy. I think this
>> is the case for all such instances using the register!() macro.
>
> The use of `as` is problematic because it disempowers the compiler
> from checking that the cast is not lossy. In other words, it is of
> course fine in the case of a `repr(u8)` enum, but if the type changes
> in a way that causes a lossy conversion, the compiler will not warn
> you.

I understand and agree with this, but why doesn't the linter limit
itself to such lossy cases (e.g. `u64 as u32`) and let the harmless ones
be?