Confusing mismatched type error

[joshlf]

If you forget to put a semicolon after the last expression in the body of a function that returns no values, rustc will infer that the type of the expression should be (). If the programmer didn't intend to return a value, but merely forgot to type a semicolon, the resulting error can be confusing. Consider, for example, the following toy program:

use std::ptr;

fn main() {
    let a = 0;
    ptr::read(&a)
}

This produces the following error message:

error[E0308]: mismatched types
 --> src/main.rs:5:15
  |
5 |     ptr::read(&a)
  |               ^^ expected (), found integral variable
  |
  = note: expected type `*const ()`
             found type `&{integer}`

In this simple example, it may be obvious, but in the somewhat more complicated code I was working with that led me to this issue, I spent a decent amount of time trying to figure out why I was supposedly passing a pointer to () to mem::replace, thus causing the type of the second argument to replace to fail to unify. It took me a while to figure out that this was actually the culprit.

[estebank]

Triage: no change.

[estebank]

Mentoring notes:

You need to take the &a expression, look at its parent to see if it is a method or function call, get its corresponding item return type and see if the return type and the argument that had a type mismatch are both the same type parameter (or really almost the same, to account for things like T and -> Option<&T>, you can use references_type for this). Once you have that, you can use the existing machinery that points at where type obligations might have come from, like the one that points at the let type in type mismatches for binding assignment.

[sulami]

I'd like to have a shot at this.

@rustbot claim

[estebank]

@sulami for an example of a similar case I worked on recently, you can look at https://github.com/rust-lang/rust/pull/106519/files#diff-f1e0bfc4e359c5e1d92ebdc4aafe6dfda183fbdbc9933a3b5e9a7fb274b9d84bR1675-R1717

[sulami]

I've pushed a WIP commit and would appreciate some early feedback if this is going in the right direction.

[estebank]

@sulami added some comments to the commit linked above your comment. Let me know if I was too terse, but the high level idea is you already have the HIR node for the call, which is great. From it you can look at the fields of the node to get the Res::Def if it is available, and with that you can get the original function/method type (I think that tcx.type_of(def_id) might work for you here, but I'm not sure). Once you have that, you need to check every single input type against the output to see if they are 1) a type parameter and 2) the same. That way you'll be able to tell that fn foo<T>(x: T) -> T { x } is affected by inference on the argument and the return type. Once we have that the rest should be easy, it's a matter of lining things up and tweaking the output to look the way we want :)