Closure captures are inconsistent between `x` and `x @ _` irrefutable patterns

[meithecatte]

Background: apart from paths, another way to make use of the precise capture of variables by closures is with irrefutable patterns:

fn main() {
    let mut a = (21, 37);
    // only captures a.0, example compiles fine
    let mut f = || {
        let (ref mut x, _) = a;
        *x = 42;
    };
    a.1 = 69;
    f();
}

One would expect this to be equivalent to an if let or match that happens to be irrefutable. However, this isn't the case:

fn main() {
    let mut a = (21, 37);
    // captures the entirety of a, example doesn't pass borrow check
    let mut f = || {
        match a {
            (ref mut x, _) => *x = 42,
        }
    };
    a.1 = 69;
    f();
}

However, one can get the code to compile again by introducing a no-op @-pattern:

fn main() {
    let mut a = (21, 37);
    // captures only a.0 again, and against all odds, the example compiles
    let mut f = || {
        match a {
            (ref mut x @ _, _) => *x = 42,
        }
    };
    a.1 = 69;
    f();
}

This suggests that the inconsistency is definitely a bug.

I have discovered this while investigating #137467, and I am working on resolving both issues. I am creating this issue to make it easy to keep track of the bug.

@rustbot claim

Meta

rustc --version --verbose:

rustc 1.87.0-nightly (f280acf4c 2025-02-19)
binary: rustc
commit-hash: f280acf4c743806abbbbcfe65050ac52ec4bdec0
commit-date: 2025-02-19
host: x86_64-unknown-linux-gnu
release: 1.87.0-nightly
LLVM version: 20.1.0

(git blame suggests that this behavior got introduced 3 years ago or so)

[compiler-errors]

This almost certainly has to do with the difference between fake read vs. borrow we introduce in maybe_read_scrutinee when there is a subpat on PatKind::Binding:

rust/compiler/rustc_hir_typeck/src/expr_use_visitor.rs

Line 557 in 617aad8

if opt_sub_pat.is_none() {

rust/compiler/rustc_hir_typeck/src/expr_use_visitor.rs

Lines 631 to 648 in 617aad8

	if needs_to_be_read {
	self.borrow_expr(discr, BorrowKind::Immutable)?;
	} else {
	let closure_def_id = match discr_place.place.base {
	PlaceBase::Upvar(upvar_id) => Some(upvar_id.closure_expr_id),
	_ => None,
	};
	self.delegate.borrow_mut().fake_read(
	&discr_place,
	FakeReadCause::ForMatchedPlace(closure_def_id),
	discr_place.hir_id,
	);
	// We always want to walk the discriminant. We want to make sure, for instance,
	// that the discriminant has been initialized.
	self.walk_expr(discr)?;
	}

Funny enough I was just looking at this code bc it's very subtle and confusing lol -- @meithecatte pls reach out on zulip if you want help investigating or fixing this issue.

[compiler-errors]

I'd also recommend that if this is separable from #137467, then ideally we fix it in a different PR, just because reasoning about (+ possibly running analysis for) the fallout of any changes to closure capture analysis should happen in parallel if possible.