error message for uninferrable type

[dherman]

The error message when an unused variable leads to an uninferrable type is confusing:

fn main() {
    let v = vec![];
}
// rustc 1.14.0 (e8a012324 2016-12-16)
// error[E0282]: unable to infer enough type information about `_`
//  --> <anon>:2:13
//   |
// 2 |     let v = vec![];
//   |             ^^^^^^ cannot infer type for `_`
//   |
//   = note: type annotations or generic parameter binding required
//   = note: this error originates in a macro outside of the current crate

@nikomatsakis pointed me to #36554. I'm not sure how much that issue was aiming to fix.

If I'm not mistaken, most (all?) of these kinds of situations occur when an expression is flowing into an unannotated local variable binding. It seems like a better error message would highlight the binding as well as the vec![] expression (or whatever the uninferrable expression is), and suggest that the variable should either be used elsewhere in the function or annotated with a type.

/cc @jonathandturner

[estebank]

#36554 is aimed at the following case:

fn foo<T>(bar: T) {}

fn main() {
  let x = vec![];
  foo(x);
}

error[E0282]: unable to infer enough type information about `T`
 --> file.rs:4:13
  |
4 |     let x = vec![];
  |             ^^^^^^ cannot infer type for `T`
  |
  = note: type annotations or generic parameter binding required

The case in this issue is slightly different.

[nikomatsakis]

I think it's basically the same underlying problem: when we are unable to infer a type, we should be as helpful as we can in telling you (a) what type we are failing to infer and (b) how can you specify it yourself. #36554 really just took a baby step by providing you at least the name of the type parameter. But it's true it was targeting the case of calling a fn.

[nikomatsakis]

So I have a plan for how to solve this. I have been talking to @cengizio who is going to take a stab at implementing it, but I wanted to write out the outlines here for future reference. Roughly speaking, the idea is that when we have an error that we need more type info about some type variable ?T, we will go search the HIR of the current function to try to find places we might put annotations that would have told us what ?T is. The first thing along these lines is to search all let definitions and see if their type includes ?T; if so, they are a candidate where an annotation might have been useful.

So the idea is that before we print the current message, we will try each of these heuristics (for now only local variables, but hopefully we'll grow more later). If we find a good suggestion for where to annotate, great, we can give a better error. Otherwise we fallback to the current one.

This current error is reported in the function need_type_info() in rustc::traits::error_reporting. This is a method defined on an InferCtxt, which has I think all the context we are going to need. But the first thing is that we need to find the current fn body -- luckily we can get that. The callers of need_type_info() have an ObligationCause which happens to have a body_id. This is the node-id of the innermost enclosing fn body, I think. Not perfect but good enough for a start. So we have to modify those callers to thread that id into need_type_info.

need_type_info() can then do a lookup using self.tcx.map.find(), which will return a librustc::hir::map::Node data structure. We expect to see a NodeBlock, I think, or maybe a NodeItem. These are the HIR nodes for the fn body. We can then setup a visitor (see librustc::hir::intravisit for docs on how to do that) and look for let statements (i.e., override visit_local, I think). For each of those, we can lookup its type in self.tables.borrow().node_types -- beware that some of them may not yet have types, if type inference is not complete.

Each type will potentially contain other inferences and so forth, so once we fetch the type for a let (let's call that let_ty) we have to "refresh" it with the most recent information by doing something like let let_ty = self.resolve_type_variables_if_possible(&let_ty);. This will give us the up-to-date let_ty. So, in our example, the type of x might wind up being Vec<?T> (where ?T is the variable we are looking for).

To see whether this type includes ?T, we can use ty.walk() which returns an iterator of all the types references (so here it would visit Vec<?T>, then ?T). We will be looking for the type ty that was passed in to need_type_info(), I imagine.

If we find it, then we can give an error pointing at the local variable, saying something like
"more type annotations needed", with a suggestion toward annotating the type of that variable. I'm not sure of the best wording, we can figure that out when we get that far I guess!

[cengiz-io]

Hello @nikomatsakis!

Thanks again for mentoring me on rust internals 😉

I started working on this.

[cengiz-io]

My PR seems to be failing only for llvm-3.7 on Travis.

Investigating now

[cengiz-io]

I think this can be closed since we landed this with #39361

[nikomatsakis]

I agree this example is fixed. I opened some new issues for other cases (e.g., #40013, #40014, and #40015)