New lint: prefer union field access to transmuting into an union

[gnzlbg]

See it live:

This code

pub unsafe fn bad(a: [u32; 4], idx: usize) -> u64 {
    union A { _a: [u32; 4], b: [u64; 2] };
    ::std::mem::transmute::<[u32; 4], A>(a).b[idx]
}

should be more idiomatically be written as this:

pub unsafe fn better(a: [u32; 4], idx: usize) -> u64 {
    union A { a: [u32; 4], b: [u64; 2] };
    A { a: a }.b[idx]  // the a: a has been added for clarity, a suffices
}

[oli-obk]

Should this only be linted if there is a field with a matching type? Or should we suggest to add a union variant?

[gnzlbg]

Should this only be linted if there is a field with a matching type?

If there is a matching type then both ways of doing type-punning via an union are semantically equivalent. So we only have to check the union for a matching type, which is easy, and we suggest something with 0% false positives, which is nice.

Or should we suggest to add a union variant?

To do this we would need to check for all the places in which the union is used and how to deduce whether adding a new union variant changes the semantics of the code or not. I think this is much harder than the previous check.

[clarfonthey]

I personally disagree with this, as it's very easy to get a size mismatch and create something you didn't intend. If this lint is implemented it should only be for a few cases.

[gnzlbg]

I personally disagree with this, as it's very easy to get a size mismatch and create something you didn't intend. If this lint is implemented it should only be for a few cases.

@clarcharr Could you elaborate? Isn't bad exactly equivalent to better ?