Avoid pointing out return span if it has nothing to do with type error

[compiler-errors]

This code:

fn f(_: String) {}

fn main() {
    let x = || {
        if true {
            return ();
        }
        f("");
    };
}

Emits this:

   Compiling playground v0.0.1 (/playground)
error[E0308]: mismatched types
 --> src/main.rs:8:11
  |
8 |         f("");
  |           ^^- help: try using a conversion method: `.to_string()`
  |           |
  |           expected struct `String`, found `&str`
  |
note: return type inferred to be `String` here
 --> src/main.rs:6:20
  |
6 |             return ();
  |                    ^^

Specifically, that note has nothing to do with the type error in question. This is because the change implemented in #84244 tries to point out the return span on any type coercion error within a closure that happens after a return statement, regardless of if the error has anything to do with it.

This is really easy to trigger -- just needs a closure (or an async) and an early return (or any other form, e.g. ? operator suffices) -- and super distracting in production codebases. I'm letting #84128 regress because that issue is much harder to fix correctly, and I can re-open that issue after this lands.

As a drive-by, I added a resolve_vars_if_possible to the coercion error logic, which leads to some error improvements. Unrelated to the issue above, though.

[rust-highfive]

r? @lcnr

(rust-highfive has picked a reviewer for you, use r? to override)

[compiler-errors]

Specifically, #84128 regresses because the error that:

struct Foo<T>(T);

fn main() {
    || {
        if false {
            return Foo(0);
        }

        Foo(())
    };
}

the given code^ emits is not being emitted in in CoerceMany, but within the argument checking logic instead. That is, because of the fact we propagate the Expectation that the return type of the block should match return Foo(0);, we end up type-checking something that looks more like:

struct Foo<T>(T);

fn main() {
    || {
        if false {
            return Foo(0);
        }

        Foo::<i32>(())
    };
}

Unfortunately, by the time we get to checking the arguments of the second Foo constructor in that closure body's tail, we don't know why we require that the 0'th argument of Foo is an integer, and not ().

[lcnr]

@bors r+ rollup

[bors]

📌 Commit 1f463ac has been approved by lcnr

It is now in the queue for this repository.