clippy --fix uses let chains and breaks existing code, when `#[cfg(feature...)]` is used

Summary

I used cargo clippy --fix and unittests failed as a result, because the code didn't do the same as before.

Reproducer

Cargo.toml:

[package]
name = "testcase"
edition = "2024"

[features]
bundle-translations = []

src/main.rs:

fn main() {
    let f = 1;
    let g = Some(1);
    let _h = Some(2);
    let mut ret = 0;
    // [...]
    // Nothing in this if statement should execute
    if f == 0 {
        if let Some(v) = g {
            ret = v;
        }
        #[cfg(feature = "bundle-translations")]
        if let Some(v) = _h {
            ret = v;
        }
    }
    assert!(ret == 0);
}  

cargo build --all-features ; cargo run, the assert passes.

clippy --fix changes this to

    // Nothing in this if statement should execute
    if f == 0
        && let Some(v) = g {
            ret = v;
        }
        #[cfg(feature = "bundle-translations")]
        if let Some(v) = _h {
            ret = v;
        }
    assert!(ret == 0);

Which means that when building the code with the bundle-translations feature enabled, the second if() will be evaluated, unlike before, and ret will be 2 instead of 0.

Pretty sure clippy got confused by the fact that the code was not enabled when it ran (the feature is off by default), but changing behavior when the feature is set is surely a --fix bug.

Version

rustc 1.91.1 (ed61e7d7e 2025-11-07)
binary: rustc
commit-hash: ed61e7d7e242494fb7057f2657300d9e77bb4fcb
commit-date: 2025-11-07
host: x86_64-unknown-linux-gnu
release: 1.91.1
LLVM version: 21.1.2

Additional Labels

No response

Start with the reported Cargo.toml and src/main.rs reproducer, then run cargo build --all-features, cargo run, and cargo clippy --fix with the feature disabled and enabled. Check that the transformed code preserves the original behavior in both feature configurations; done means --fix no longer changes control flow across #[cfg] boundaries.