Closed
Description
Summary
Hello team!
I've noticed that using type aliases for built-in arithmetic types doesn't play especially well with the cast_lossless
lint when it comes to casting to more capacious siblings.
I would expect the type alias to be adopted for associated warnings and fixes, rather than the underlying type itself, producing a minor semantic disconnect, and failed compilations in a somewhat confusing place should the type alias ever change. See below for a very short example.
Thanks,
Iain
Reproducer
I tried this code:
#![warn(clippy::pedantic)]
fn twelve_gets_a_promotion() {
type Big = u64;
let u8_twelve = 12_u8;
let big_twelve = u8_twelve as Big;
dbg!(big_twelve);
}
I expected to see this happen:
(warning)
casting `u8` to `Big` may become silently lossy if you later change the type
(fix)
fn twelve_gets_a_promotion() {
type Big = u64;
let u8_twelve = 12_u8;
let big_twelve = Big::from(u8_twelve);
dbg!(big_twelve);
}
Instead, this happened:
(warning)
casting `u8` to `u64` may become silently lossy if you later change the type
(fix)
fn twelve_gets_a_promotion() {
type Big = u64;
let u8_twelve = 12_u8;
let big_twelve = u64::from(u8_twelve);
dbg!(big_twelve);
}
Version
rustc 1.73.0-nightly (d12c6e947 2023-08-01)
binary: rustc
commit-hash: d12c6e947ceacf3b22c154caf9532b390d8dc88a
commit-date: 2023-08-01
host: x86_64-pc-windows-msvc
release: 1.73.0-nightly
LLVM version: 16.0.5
Additional Labels
No response