Confusing cmp_owned false positive with <u32 as From<midly::primitive::u28>>::from

[PatchMixolydic]

Summary

Unfortunately, I couldn't minimize it, but I tried linting this code. Specifically, this is the area that gave me grief:

// event.delta: midly::primitive::u28
// ticks_since_last_update: &mut u32; comes from an iterator
if u32::from(event.delta) > *ticks_since_last_update {
    // Not ready to proceed yet
    break;
}

I saw this happen:

warning: this creates an owned instance just for comparison
  --> src/lib.rs:96:24
   |
96 |                     if u32::from(event.delta) > *ticks_since_last_update {
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ try implementing the comparison without allocating
   |
   = note: `#[warn(clippy::cmp_owned)]` on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#cmp_owned

I expected to see this happen:

Nothing. This comparison is fine as-is since u32: Copy, and removing the deref fails to compile. What might be the issue? Strangely enough, removing u32::from silences the lint, even though From<midly::primitive::u28> for u32 doesn't allocate (it just unwraps a newtype, which only copies a u32).

Lint Name

cmp_owned

Reproducer

See above

Version

rustc 1.62.0-nightly (1f7fb6413 2022-04-10)
binary: rustc
commit-hash: 1f7fb6413d6d6c0c929b223e478e44c3db991b03
commit-date: 2022-04-10
host: x86_64-unknown-linux-gnu
release: 1.62.0-nightly
LLVM version: 14.0.0

Additional Labels

No response

[Jarcho]

cmp_owned triggers when From::from is used in a comparison which could be done without it. Over-zealous in this case as converting to a u32 shouldn't ever need an allocation.

I would say the comparison is better done without the conversion anyways, but that's a style thing rather than a performance issue.