transmute_undefined_repr: false positive when TypeId has been checked

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

Start with the transmute_undefined_repr lint and reproduce the diagnostic using the supplied Rust snippet and rustc version. Determine whether the TypeId check is sufficient to establish the layouts are compatible; done means resolving whether this case should remain diagnosed or be accepted.