Clippy thinks casting u8/u16 to usize is infallible

let u: usize = u16::MAX.try_into().unwrap(); Clippy suggests using .into().
warning: use of a fallible conversion when an infallible one could be used
Although we use 64-bit targets nowadays, but I think the conversion is still fallible if we need to compile for targets using 8-bit or even smaller pointer size, e.g, microcontroller or single chip?

[taiki-e]

Rust (and C99) pointers must be at least 16-bit. From #49305:

Their infallibility is supported by the C99 standard which (indirectly) requires pointers to be at least 16 bits.

Even in architectures with 8-bit registers like the AVR, 16-bit pointers are used.

rust/compiler/rustc_target/src/spec/targets/avr_none.rs

Line 14 in 846cb1e

pointer_width: 16,

@saethlin Rust has its own ABI, which isn't stable yet, sometimes needs #[repr(C)] on struct to make struct compatible with C. It seems that Rust ABI doesn't need to use C standard, and hardware may not use 8 bits per byte; e.g, if a new architecture uses separated layouts for RAM and CPU, e.g, CPU uses 8 bits per byte but RAM uses 128 bits per byte. So it may not relate to C standard due to Rust has its own ABI.

[taiki-e]

e.g, if a new architecture uses separated layouts for RAM and CPU, e.g, CPU uses 8 bits per byte but RAM uses 128 bits per byte.

• Is there actually such a CPU?
• If it exists, is there any language other than assembly language or architecture-specific languages that supports that CPU?

Note that Rust cannot support all CPUs. Generally, it cannot support CPUs that other high-level programming languages such as C cannot support. e.g., #146889 (comment)

[saethlin]

@venezuela-wq57 usize documents that it is pointer-sized, and it has infallible conversion from u16. Rust does not support platforms with 8-bit pointers/addresses. In addition, while Rust does not have a completely stable ABI, we do make some guarantees about the ABI of specific types. For example, u8 clearly documents that it is 8 bits. If you have a platform with CHAR_BIT=6, Rust doesn't support that.

We do not and will not support every conceivable architecture, in part because doing so would mean we cannot make many of the guarantees about memory representation that unsafe code wants to rely on.

If you want to try to argue for supporting more platforms, you could try https://github.com/rust-lang/unsafe-code-guidelines/ or https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem but I am giving you fair warning that you will probably get a lot more conversation than my response here but with the same conclusion.