Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

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

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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