transmute_undefined_repr: false positive when TypeId has been checked

[dtolnay]

Summary

This might be wontfix territory, but here is an interesting case derived from https://github.com/AleoHQ/snarkVM/blob/71e39319b6fb5bcaddd48c95d32e2f80ac103954/algorithms/src/msm/variable_base/cuda.rs.

Vec<u32> is guaranteed to have the same layout as Vec<u32>.

Lint Name

transmute_undefined_repr

Reproducer

use std::any::TypeId;
use std::mem;

fn f<T: 'static>(bases: Vec<T>) -> Vec<u32> {
    if TypeId::of::<T>() != TypeId::of::<u32>() {
        unimplemented!();
    }

    unsafe { mem::transmute::<Vec<T>, Vec<u32>>(bases) }
}

error: transmute from `std::vec::Vec<T>` to `std::vec::Vec<u32>`, both of which have an undefined layout
 --> src/main.rs:9:14
  |
9 |     unsafe { mem::transmute::<Vec<T>, Vec<u32>>(bases) }
  |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[deny(clippy::transmute_undefined_repr)]` on by default
  = note: two instances of the same generic type (`Vec`) may have different layouts
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#transmute_undefined_repr

Version

rustc 1.61.0-nightly (f0c4da499 2022-03-01)
binary: rustc
commit-hash: f0c4da49983aa699f715caf681e3154b445fb60b
commit-date: 2022-03-01
host: x86_64-unknown-linux-gnu
release: 1.61.0-nightly
LLVM version: 14.0.0

Additional Labels

No response

[Jarcho]

This is definitely not detectable in general. The check could very easily be in a different function.

It would be possible to detect a conversion from a generic type to a concrete type and either add a note to the lint output about checking the type id, or not lint under the assumption that there is a check.

[dtolnay]

In my opinion we should aim to not lint if the two types could statically be a compatible pair of types.

The bar for a correctness lint that tells you "your types both have undefined layout, so what you are doing is UB" is very high. If there is some other high-false-positive checking that people want beyond this, that needs to not be a correctness lint. It could be a restriction lint instead.

Some examples that I believe should not trigger this lint, where T is a generic parameters of some surrounding scope:

• transmute::<Vec<T>, Vec<u32>>
• transmute::<Vec<u32>, Vec<T>>
• transmute::<*const Ty2<u32, i32>, &Ty2<u32, T>>

[dtolnay]

Does this need to be reopened? #8553 says "Partially fixes #8499"

[Jarcho]

Type parameters are handled, but associated types are not. So Vec<T::Type> will still be a problem.