fix incomplete diagnostic notes when closure returns conflicting for genric type #84244
Conversation
|
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ |
|
📌 Commit af90cac has been approved by |
bors
added
S-waiting-on-bors
| LL | Foo(()) | ||
| | ^^ expected integer, found `()` | ||
| | | ||
| note: return type inferred to be `{integer}` here |
There was a problem hiding this comment.
It's not really the 'return type' that's being inferred here
There was a problem hiding this comment.
I missed that, thanks. I will fix it.
There was a problem hiding this comment.
Shouldn't it either be "return type inferred to be Foo<{integer}> here" with span of Foo(0) indicated; or else "{integer} inferred here" (with the span of 0 indicated)? (My personal view, FWIW, is that the former is a tad more informative but either seems fine).
As it is, it's a bit confusing: essentially "{integer} inferred here" but Foo(0) indicated.
There was a problem hiding this comment.
I have some issue to solve this I am not sure how do do it. I found that the suggestions is emitted from
compiler\rustc_typeck\src\check\fn_ctxt\checks.rs: check_argument_types
compiler\rustc_typeck\src\check\demand.rs: demand_coerce
compiler\rustc_typeck\src\check\demand.rs: demand_coerce_diag
compiler\rustc_typeck\src\check\demand.rs: emit_coerce_suggestions
is there a way to get the return type from the FnCtxt ?
…-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
…-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
|
☀️ Test successful - checks-actions |
…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.
fixes #84128
Correctly report the span on for conflicting return type in closures