@Esteban Küber for the "expected type foo found bar" style messages, who is "expecting"? Can we change that to explicitly say what expects it?
error[E0308]: mismatched types --> src/main.rs:4:10 | 4 | demo("hi"); | ^^^^ expected `i32`, found `&str`
error[E0308]: mismatched types --> src/main.rs:4:10 | 4 | demo("hi"); | ^^^^ the function `demo` expected `i32`, found `&str`
expected this argument to be a `i32`, but it is `&str`
I guess this does occur sometimes:
--- expected `f64` because of return type
some cases do highlight the site of expectation like
error[E0308]: mismatched types --> src/main.rs:5:18 | 5 | let b: i32 = "123"; | --- ^^^^^ expected `i32`, found `&str` | | | expected due to this
though most of the time i do find E0308 confusing because it is not very clear whether the marked expression is the "expected" or the "found"
My gut tells me that if we say what / why it's expected (more frequently, perhaps), then it would be more quickly digested. I'm pretty sure I've trained my brain to just ignore the "expected" / "found" text.
The pointed element should always be the found one
The problem we have is that these cases usually come from obligations
I've been working in this but the cases that are left are becoming harder and harder
And sadly I'm many cases all I can do is reconstruct what went wrong because we drop a lot of info during typeck
Keeping that info around would balloon mem usage, which is a no-no
@Esteban Küber I wonder if we've explored e.g. re-running typeck in "collection" mode if it detects an error at first to gather better explanations
I'd guess it'd be pretty hard to make that work well? But I don't think I've seen PRs in that direction at all
I've looked into it, but I doubt well ever get good at global analysis as things stand. Anything inside a given FnCtxt has potential