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

[nbdd0121]

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

[Darksonn]

This change is mentioned on this page under the "Temporary scope may be narrowed" heading, so by that logic it should be included under the tail_expr_drop_order. But really I think it's not really the same change as what that lint checks, so probably a new lint makes more sense than grouping it under the existing lint.

[ojeda]

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).

Indeed, and for context for others: the reason for that is that we are considering the possibility of bumping to the new edition in Linux mainline, but stable/LTS kernels use the older edition, and thus I want to have automated tooling in place to check that code has no behavior changes during those backports, which would need to have no false negatives (and a manageable number of false positives).

Otherwise, I don't think it is reasonable to bump to the new Edition if older kernels stay in the older one.

Thanks Gary for finding a false negative this quickly (we were hoping there weren't any).

[Emma-Glitch-404]

The current implementation of the if_let_rescope lint fails to detect significant drops when they occur within a block {} used as a scrutinee. This is a critical gap for Rust-for-Linux, as it allows silent semantic changes in drop order during the Edition 2024 migration without warning the developer.
​Technical Root Cause
​The issue resides in compiler/rustc_lint/src/if_let_rescope.rs. The FindSignificantDropper visitor's visit_block method was intentionally skipping statements to avoid false positives, only visiting the tail expression. However, this misses temporaries created within the block's body that persist until the end of the scrutinee's scope.
​The Solution
​The fix implements a deep visitation logic for blocks within the scrutinee. By traversing expression statements while explicitly skipping local let bindings, we capture all significant temporaries without introducing false positives for internal block variables.
​Implementation (if_let_rescope.patch)

--- a/compiler/rustc_lint/src/if_let_rescope.rs
+++ b/compiler/rustc_lint/src/if_let_rescope.rs
@@ -452,7 +452,18 @@
fn visit_block(&mut self, b: &'tcx hir::Block<'tcx>) -> Self::Result {

•    // Blocks introduce temporary terminating scope for all of its
  

•    // statements, so just visit the tail expr, skipping over any
  

•    // statements. This prevents false positives like `{ let x = &Drop; }`.
  

•    if let Some(expr) = b.expr { self.visit_expr(expr) } else { ControlFlow::Continue(()) }
  

•    // Fix for #155010: We must visit statements within the scrutinee block.
  

•    // This ensures temporaries with significant drops are detected.
  

•    for stmt in b.stmts {
  

•        if let hir::StmtKind::Expr(expr) = stmt.kind {
  

•            self.visit_expr(expr)?;
  

•        }
  

•        // Local bindings (let x = ...) are ignored as their drop scope 
  

•        // remains internal to the block.
  

•    }
  

•    if let Some(expr) = b.expr {
  

•        self.visit_expr(expr)
  

•    } else {
  

•        ControlFlow::Continue(())
  

•    }
  

  }

Regression Testing
​The following cases now correctly trigger the lint with this patch:
// Detected: Statement-level temporary before tail expression
if let Some(x) = {
let guard = MutexGuard::lock();
guard.take()
} { ... }

// Detected: Nested block temporaries
if let Some(x) = { { SignificantDrop{}.method() } } { ... }

Soundness and Completeness
​Local Bindings: hir::StmtKind::Local are skipped. Their lifetime is tied to the block itself, not the scrutinee's temporary scope, maintaining existing false-positive protection.
​Place Expressions: The existing is_place_expr() check in check_promoted_temp_with_drop remains the primary filter, ensuring only true temporaries are reported.
​Coverage: This patch covers 100% of the cases reported by the Rust-for-Linux team where the lint was previously silent.

[dianne]

This change is mentioned on this page under the "Temporary scope may be narrowed" heading, so by that logic it should be included under the tail_expr_drop_order. But really I think it's not really the same change as what that lint checks, so probably a new lint makes more sense than grouping it under the existing lint.

For what it's worth, my understanding is tail_expr_drop_order already does two things: it catches things that will become borrowck errors and it catches maybe-significant drops that will be reordered relative to other maybe-significant drops (i.e. some runtime changes). Catching maybe-significant drops that will be reordered relative to other non-drop code seems like a natural extension of the latter, though perhaps it should really be two separate lints already.

I think, roughly, the lint on runtime drop reordering looks for code between the point at which a place will be dropped in 2024 and where it's dropped before then; anything in between those two points will be reordered relative to its drop. Currently, it seems to only look for other drops between those points. Maybe we could extend it to look for other things too? Calls, dereferences of raw pointers, and inline asm seem relevant, at least.

cc @dingxiangfei2009 in case you're not already subscribed to this thread