Field within opaque type is not captured by closure under old solver

@theemathas

I tried this code:

pub fn wut() -> impl Sized {    
    struct Foo { x: u32 }

    if false {
        let foo = wut();
        let _closure = move || {
            // let foo = foo; // Works if this is uncommented
            let Foo { x } = foo;
            let _y = x;
        };
    }
    
    Foo { x: 7 }
}

(Thanks to @theemathas for a minimization not requiring TAIT.)

I expected to see this happen: Compiles successfully.

Instead, this happened:

   Compiling playground v0.0.1 (/playground)
error[E0381]: used binding `x` isn't initialized
 --> src/lib.rs:9:22
  |
8 |             let Foo { x } = foo;
  |                       - binding declared here but left uninitialized
9 |             let _y = x;
  |                      ^ `x` used here but it isn't initialized

warning: value captured by `foo.x` is never read
 --> src/lib.rs:8:29
  |
8 |             let Foo { x } = foo;
  |                             ^^^
  |
  = help: did you mean to capture by reference instead?
  = note: `#[warn(unused_assignments)]` (part of `#[warn(unused)]`) on by default

For more information about this error, try `rustc --explain E0381`.
warning: `playground` (lib) generated 1 warning
error: could not compile `playground` (lib) due to 1 previous error; 1 warning emitted

Meta

(Tested on playground with stable 1.94.1 and nightly 1.96.)

The failure only occurs under edition 2021 or later (since it requires precise-capture), and does not occur under -Znext-solver.

Triggering this issue without TAIT requires some pretty contrived code, but with TAIT it's a lot more plausible:

rust/tests/ui/type-alias-impl-trait/issue-96572-unconstrained.rs

Lines 15 to 24 in c29effd

    
           fn upvar() { 
        
               #[derive(Copy, Clone)] 
        
               struct Foo((u32, u32)); 
        
               type T = impl Copy; 
        
               let foo: T = Foo((1u32, 2u32)); 
        
               let x = move || { 
        
                   let Foo((a, b)) = foo; 
        
               }; 
        
           }

This existing test currently doesn't trigger the bug, but actually using a or b in the closure would produce a similar error.

@meithecatte

Possibly related to #119786. cc @meithecatte

For additional background, I noticed the issue while looking into situations where this code fails to create a binding for a PatKind::Binding node, because place is None:

rust/compiler/rustc_mir_build/src/builder/matches/match_pair.rs

Lines 218 to 227 in bf4fbfb

    
           // Then push this binding, after any bindings in the subpattern. 
        
           if let Some(source) = place { 
        
               extra_data.bindings.push(super::SubpatternBindings::One(super::Binding { 
        
                   span: pattern.span, 
        
                   source, 
        
                   var_id: var, 
        
                   binding_mode: mode, 
        
                   is_shorthand, 
        
               })); 
        
           }

Rollup merge of rust-lang#155280 - Zalathar:opaque-capture-bug, r=Jon…

Unrolled build for #155280

Rollup merge of rust-lang#162145 - Randl:test-fixed-issues-2, r=jackh726

Navigation Menu

Repository navigation

Field within opaque type is not captured by closure under old solver #155151

Meta

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	fn upvar() {
	#[derive(Copy, Clone)]
	struct Foo((u32, u32));

	type T = impl Copy;
	let foo: T = Foo((1u32, 2u32));
	let x = move \|\| {
	let Foo((a, b)) = foo;
	};
	}

	// Then push this binding, after any bindings in the subpattern.
	if let Some(source) = place {
	extra_data.bindings.push(super::SubpatternBindings::One(super::Binding {
	span: pattern.span,
	source,
	var_id: var,
	binding_mode: mode,
	is_shorthand,
	}));
	}

Field within opaque type is not captured by closure under old solver #155151

Description

Meta

Activity

Zalathar commented on Apr 11, 2026

Zalathar commented on Apr 11, 2026

theemathas commented on Apr 11, 2026

Zalathar commented on Apr 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions