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

Tamir Duberstein
2025-06-24T12:29:59Z

On Tue, Jun 24, 2025 at 5:24 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> 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?

Ah, that's a different lint. They are all explained in the docs
probably better than I can:

https://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless
https://rust-lang.github.io/rust-clippy/master/index.html#cast_possible_truncation
https://rust-lang.github.io/rust-clippy/master/index.html#cast_possible_wrap
https://rust-lang.github.io/rust-clippy/master/index.html#cast_sign_loss

They are all allow-by-default though, because it is expected that
*sometimes* you do want to do the lossy thing and there's no other way
to express that.