Skip to content

Incomplete diagnostic notes when closure returns conflicting instantiations of generic type #84128

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
eggyal opened this issue Apr 12, 2021 · 4 comments · Fixed by #84244
Open
Assignees
Labels
A-closures Area: Closures (`|…| { … }`) A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference C-enhancement Category: An issue proposing an enhancement or a PR with one. D-papercut Diagnostics: An error or lint that needs small tweaks. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@eggyal
Copy link
Contributor

eggyal commented Apr 12, 2021

Given the following code (playground):

struct Foo<T>(T);

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

        Foo(())
    };
}

The current output is:

error[E0308]: mismatched types
 --> src/main.rs:9:13
  |
9 |         Foo(())
  |             ^^ expected integer, found `()`

Ideally the output should look like:

error[E0308]: mismatched types
 --> src/main.rs:9:13
  |
9 |         Foo(())
  |             ^^ expected integer, found `()`
  |
note: return type inferred to be `Foo<{integer}>` here
 --> src/main.rs:6:20
  |
6 |             return Foo(0);
  |                    ^^^^^^

Since #78235, notes have been provided when the returned types are entirely different—but they do not appear when they are the same base type with different generic type parameters. cc @Aaron1011

@rustbot label: A-closures A-diagnostics A-inference C-enhancement D-papercut

@eggyal eggyal added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 12, 2021
@rustbot rustbot added A-closures Area: Closures (`|…| { … }`) A-inference Area: Type inference C-enhancement Category: An issue proposing an enhancement or a PR with one. D-papercut Diagnostics: An error or lint that needs small tweaks. labels Apr 12, 2021
@khrj
Copy link

khrj commented Apr 12, 2021

Reference

@ABouttefeux
Copy link
Contributor

@rustbot claim

jyn514 pushed a commit to jyn514/rust that referenced this issue Apr 16, 2021
…-suggest, r=estebank

fix incomplete diagnostic notes when closure returns conflicting for genric type

fixes rust-lang#84128
Correctly report the span on for conflicting return type in closures
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Apr 17, 2021
…-suggest, r=estebank

fix incomplete diagnostic notes when closure returns conflicting for genric type

fixes rust-lang#84128
Correctly report the span on for conflicting return type in closures
@bors bors closed this as completed in 080d302 Apr 17, 2021
@compiler-errors
Copy link
Member

Gonna reopen this since I regressed this (intentionally, the original fix had some side-effects)

@compiler-errors
Copy link
Member

@rustbot claim

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 6, 2022
…pan, r=lcnr

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

This code:

```rust
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 rust-lang#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 rust-lang#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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-closures Area: Closures (`|…| { … }`) A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference C-enhancement Category: An issue proposing an enhancement or a PR with one. D-papercut Diagnostics: An error or lint that needs small tweaks. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants