warn transmute about non-exhaustives

What it does

This lint emit warnings in following condition.

let T is before-transmute type, and U is after-transmute type.
if valid range of T does not covered by U, this is UB.
This lint bounds T to integral types or enum with #[repr(u_)] or #[repr(i_)] and its all variants does not have fields, and U to #[repr(u_)] or #[repr(i_)].

TODO: If T is enum with #[repr(C)] and its all variants does not have fields, treat it as #[repr(u<GuessedWidth>)].

More spefically:

If their value may not overwrap (i.e. integer to one-element enum), emits warning.
If their value never overwrap (i.e. Foo { One = 1 } and Bar { Two = 2 }), transmuting between them is 100% UB and emits error (this should be given another lint name, like transmute_non_overwrapping_enums under correctness)
If U is 100% exhaustive over integral possible values (i.e. #[repr(u8)] and having 256 elements), this lint does not fire.

Lint Name

transmute_integer_to_out_of_enum

Category

suspicious

Advantage

• Avoids some form of UB.

Drawbacks

No response

Example

#[repr(u8)]
enum Foo {
    Zero,
    One,
    Two,
}

let invalid = 3;
let ub: Foo = unsafe { std::mem::transmute(invalid) };
//                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

Could be written as:

impl Foo {
    fn new(inner: u8) -> Option<Foo> {
        // match clause
    }
}
let invalid = 3;
let not_ub: Foo = Foo::new(invalid).expect_err("should not succeed")

The issue does not name files, tests, or an entry point. Start by reviewing the proposed transmute_integer_to_out_of_enum behavior and the Rust transmute and repr rules described here. Done means the lint handles the listed integer and fieldless repr enum combinations, including exhaustive cases, and reports the specified warnings or errors.