Suggest {to,from}_ne_bytes when people use transmute between arrays and integers

[scottmcm]

Code

fn bytes_at_home_1(a: [u8; 4]) -> u32 {
    unsafe { std::mem::transmute(a) }
}

fn bytes_at_home_2(x: u32) -> [u8; 4] {
    unsafe { std::mem::transmute(x) }
}

Current output

(no warnings)

Desired output

Warning: use the safe alternative instead
|
|    unsafe { std::mem::transmute(a) }
|             ^^^^^^^^^^^^^^^^^^^ This can be done with `u32::from_ne_bytes(a)` instead
|
hint: there's also `from_le_bytes` and `from_ne_bytes` if you expect a particular byte order

Warning: use the safe alternative instead
|
|    unsafe { std::mem::transmute(x) }
|             ^^^^^^^^^^^^^^^^^^^ This can be done with `x.to_ne_bytes()` instead
|
hint: there's also `to_le_bytes` and `to_ne_bytes` if you expect a particular byte order

Rationale and extra context

I see people doing this a bunch, like it just came up in Discord.

It would be nice to point them to the safe alternative when possible.

Other cases

Rust Version

Playground nightly ⬇

Anything else?

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=a89dfdaa49736b9d106b2099ca48ddd7

[kpreid]

Some other byte-reinterpretations that could be linted against on the same premise, that don’t involve arrays:

• iNN ↔ uNN
• bool ↔ u8
• char ↔ u32

[bend-n]

@rustbot claim

[hanna-kruppe]

FWIW, clippy already has a bunch of warn-by-default lints for transmutes that can be done with safe constructors or need extra checks to be sound (including some already mentioned in this thread, but also int<->float, &str <-> &[u8], NonZeroT <-> T). May be worth uplifting and expanding all of those if there’s appetite for this kind of lint in rustc.

[scottmcm]

@hanna-kruppe To me, the thing that makes to_ne_bytes worth warning in rustc is that it removes unsafe code.

I'm definitely a fan of having clippy suggest better unsafe ways to do transmutes, but I don't know that it would necessarily meet the rustc bar if the replacement is still unsafe.

[hanna-kruppe]

Sure, as long as there’s some consistent reason for what’s uplifted and what isn’t and we aren’t missing clippy existing lints just because nobody looked.

[bend-n]

What about std::simd types? we could add those in too, maybe?
Or [[T:N];N] -> [T; N * N] via as_flattened