False negative in edition 2024 migration lints where point of drop is reordered against other side-effects

I tried this code:

#![warn(rust_2024_compatibility)]

unsafe extern "C" {
    safe fn foo();
    safe fn bar();
}

struct SignificantDrop {}

impl SignificantDrop {
    fn take(&mut self) -> Option<usize> {
        Some(1)
    }
}

impl Drop for SignificantDrop {
    #[inline(always)]
    fn drop(&mut self) {
        foo();
    }
}

#[unsafe(no_mangle)]
fn f() {
    if let Some(_x) = {SignificantDrop{}.take()} {
        bar();
    }
}

I expected to see this happen: lint fired because the drop and function call are going to be reordered.

Instead, this happened: no lints, but generated code are different. https://godbolt.org/z/Mvd4x5o5h

This is an example code recently encountered in Rust-for-Linux: https://lore.kernel.org/all/20260403-lockhold-v1-1-c332b56cd8ae@google.com/. We hoped that migration to 2024 would fix the issue (and it does) but surprising this does not cause the migration lint to fire, meaning that automated migration between 2021 to 2024 has a hole (as semantics are changed).

Meta

rustc --version --verbose:

rust version 1.94.1 (e408947bf 2026-03-25)

@rustbot label +L-false-negative +A-edition-2024 +A-rust-for-linux