When type inference depends on the content of a closure, earlier statements do not make use of this information

[dylanede]

Minimal example:

fn main() {
    // Behaviour does not appear linked to the use of unimplemented!()
    let x = unimplemented!();

    // Move the definition of g above this line to get this to compile
    x.0; // E0282: cannot infer type for `_`
    let g = || {
        let x: (i32, i32) = x;
    };
}

playground

This appears in stable, beta and nightly.

This appears to be a case where type inference should not depend on the order of these statements in the function.

This problem can be a deal-breaker when unnameable types are involved and reordering the statements isn't possible.

[leoyvens]

You're right, type checking should not depend on the order of the statements, however it's a known limitation that sometimes it does, notably in indexing x[0], field access x.0 and method cals x.foo(). You don't even need the closure for that:

let x = unimplemented!();
// Move `let x` above this line to get this to compile
x.0; // E0282: cannot infer type for `_`
     // note: type must be known at this point
let x: (i32, i32) = x;

If you look closely at the nightly error you'll see the note: type must be known at this point which marks the fact that type checking failed early. We hope to improve this in the future, but for now I'm closing this as a known issue. Thank you for the report!

[dylanede]

@leodasvacas, OK, is there an issue tracking this somewhere then? If not, maybe one should be created.

[leoyvens]

@dylanede We don't have a comprehensive issue tracking this, mostly because we don't know if we'll ever be able to actually fix this, but it would be good to have one. #50692 is fundamentally about the same thing, also #36418 and #8280. rust-lang/chalk#105 is about the first thing we need to do to improve this.