clippy::eager_transmute: this transmute is always evaluated eagerly, even if the condition is false

error: this transmute is always evaluated eagerly, even if the condition is false
  --> main.rs:12:33
   |
12 |     (op < 4).then_some(unsafe { std::mem::transmute(op) })
   |                                 ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#eager_transmute
   = note: `#[deny(clippy::eager_transmute)]` on by default
help: consider using `bool::then` to only transmute if the condition holds
   |
12 -     (op < 4).then_some(unsafe { std::mem::transmute(op) })
12 +     (op < 4).then(|| unsafe { std::mem::transmute(op) })
   |

#[repr(u8)]
enum Opcode {
    Add = 0,
    Sub = 1,
    Mul = 2,
    Div = 3
}

fn int_to_opcode(op: u8) -> Option<Opcode> {
    (op < 4).then_some(unsafe { std::mem::transmute(op) })
}

let temp: Foo = unsafe { std::mem::transmute(op) };
(0 < 4).then_some(temp)

#[allow(clippy::eager_transmute)]
fn my_function() { /* ... */ }

[lints.clippy]
eager_transmute = "allow"

cargo clippy -- -A clippy::eager-transmute

Clippy's own documentation

What it does

Checks for integer validity checks, followed by a transmute that is (incorrectly) evaluated eagerly (e.g. using bool::then_some).

Why is this bad?

Eager evaluation means that the transmute call is executed regardless of whether the condition is true or false. This can introduce unsoundness and other subtle bugs.

Example

Consider the following function which is meant to convert an unsigned integer to its enum equivalent via transmute.

#[repr(u8)]
enum Opcode {
    Add = 0,
    Sub = 1,
    Mul = 2,
    Div = 3
}

fn int_to_opcode(op: u8) -> Option<Opcode> {
    (op < 4).then_some(unsafe { std::mem::transmute(op) })
}

This may appear fine at first given that it checks that the u8 is within the validity range of the enum, however the transmute is evaluated eagerly, meaning that it executes even if op >= 4!

This makes the function unsound, because it is possible for the caller to cause undefined behavior (creating an enum with an invalid bitpattern) entirely in safe code only by passing an incorrect value, which is normally only a bug that is possible in unsafe code.

One possible way in which this can go wrong practically is that the compiler sees it as:

let temp: Foo = unsafe { std::mem::transmute(op) };
(0 < 4).then_some(temp)

and optimizes away the (0 < 4) check based on the assumption that since a Foo was created from op with the validity range 0..3, it is impossible for this condition to be false.

In short, it is possible for this function to be optimized in a way that makes it never return None, even if passed the value 4.

This can be avoided by instead using lazy evaluation. For the example above, this should be written:

fn int_to_opcode(op: u8) -> Option<Opcode> {
    (op < 4).then(|| unsafe { std::mem::transmute(op) })
             ^^^^ ^^ `bool::then` only executes the closure if the condition is true!
}

From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.

Related lints

• deprecated_semverthe since field must contain a semver-compliant version
• derive_ord_xor_partial_ordLints against manual PartialOrd and Ord implementations for types with a derived Ord or PartialOrd implementation
• derived_hash_with_manual_eqLints against manual PartialEq implementations for types with a derived Hash implementation
• enum_clike_unportable_variantC-like enum variant discriminant is not portable to 32-bit targets
• eq_opChecks for equal operands to comparison, logical and bitwise, difference and division binary operators (==, >, etc., &&, ||, &, |, ^, - and /)
• erasing_opthis operation will always return zero. This is likely not the intended outcome

All 847 Clippy lints · Rust compiler errors · Cargo.toml checker