`pin!()` has incorrect/unexpected drop order inside if-let.

[theemathas]

My intuition is that, with regards to drop order, pin!(expr) should behave like &mut expr. However, this is not the case inside let chains.

use std::pin::pin;

struct LoudDrop(&'static str);
impl Drop for LoudDrop {
    fn drop(&mut self) {
        println!("{}", self.0);
    }
}

fn main() {
    if let x = LoudDrop("0")
        && let y = pin!(LoudDrop("1"))
    {}
    if let x = LoudDrop("3")
        && let y = &mut LoudDrop("2")
    {}
}

The above code outputs: 0, 1, 2, 3. It should output 1, 0, 2, 3.

cc @m-ou-se

Discovered in #141295 (comment)

Note that pin!() started being implemented with super let in version 1.88.0, the same version where let chains were stabilized.

@rustbot labels +A-pin +F-let_chains +A-destructors +F-super_let

Meta

Reproducible on the playground with version 1.89.0 and version 1.91.0-nightly (2025-08-11 1ebbd87a62ce96a72b22)

Related PRs:

• fix drop scope for super let bindings within if let #145342

[theemathas]

This issue needs a decision on whether to change the behavior to make more sense. Doing so is a breaking change which affects subtle run time semantics. This decision might also affect the upcoming stabilization of if-let match guards.

@rustbot labels +lang-nominated

(Sorry if this is inappropriate.)

[rustbot]

Error: Label lang-nominated can only be set by Rust team members

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[theemathas]

I just realized that the situation is even worse than I thought: The value inside pin!() can be dropped after the entire if-let has finished executing.

This code prints 0, 1, 2.

use std::pin::pin;

struct LoudDrop(&'static str);
impl Drop for LoudDrop {
    fn drop(&mut self) {
        println!("{}", self.0);
    }
}

fn main() {
    (
        if let x = LoudDrop("0")
            && let y = pin!(LoudDrop("2"))
        {},
        println!("1")
    );
}

[dianne]

Implementation-wise, I believe this is because of an inconsistency between super let's binding scoping rules and more general temporary scoping rules. For super let outside of an extending let statement initializer, its bindings use the nearest enclosing scope marked as a temporary destruction scope by an immediately enclosing ScopeData::Destruction:

rust/compiler/rustc_hir_analysis/src/check/region.rs

Lines 493 to 499 in 1553adf

	while let Some(s) = visitor.cx.var_parent {
	let parent = visitor.scope_tree.parent_map.get(&s).cloned();
	if let Some(Scope { data: ScopeData::Destruction, .. }) = parent {
	break;
	}
	visitor.cx.var_parent = parent;
	}

However, this isn't what if expressions use to mark its condition's temporary scope; they use ScopeData::IfThenRescope:

rust/compiler/rustc_middle/src/ty/rvalue_scopes.rs

Lines 41 to 69 in 1553adf

	while let Some(&p) = region_scope_tree.parent_map.get(&id) {
	match p.data {
	ScopeData::Destruction => {
	debug!("temporary_scope({expr_id:?}) = {id:?} [enclosing]");
	return (Some(id), backwards_incompatible);
	}
	ScopeData::IfThenRescope | ScopeData::MatchGuard => {
	debug!("temporary_scope({expr_id:?}) = {p:?} [enclosing]");
	return (Some(p), backwards_incompatible);
	}
	ScopeData::Node
	| ScopeData::CallSite
	| ScopeData::Arguments
	| ScopeData::IfThen
	| ScopeData::Remainder(_) => {
	// If we haven't already passed through a backwards-incompatible node,
	// then check if we are passing through one now and record it if so.
	// This is for now only working for cases where a temporary lifetime is
	// *shortened*.
	if backwards_incompatible.is_none() {
	backwards_incompatible = region_scope_tree
	.backwards_incompatible_scope
	.get(&p.local_id)
	.copied();
	}
	id = p
	}
	}
	}

Ideally, the logic should be shared. In case this is decided to be a bug, @rustbot claim

Funnily, this only recently changed for guards; #143376 made them consistent with if expressions in how their scopes are set up, but that meant breaking the drop order for super let in the let chain.