E0194 needs to be updated to new format

[sophiajt]

From: src/test/compile-fail/E0194.rs

Error E0194 needs a span_label, updating it from:

error[E0194]: type parameter `T` shadows another type parameter of the same name
  --> src/test/compile-fail/E0194.rs:13:5
   |
13 |     fn do_something_else<T: Clone>(&self, bar: T); //~ ERROR E0194
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

To:

error[E0194]: type parameter `T` shadows another type parameter of the same name
  --> src/test/compile-fail/E0194.rs:13:5
   |
13 |     fn do_something_else<T: Clone>(&self, bar: T); //~ ERROR E0194
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `T` shadows another type parameter

Bonus: the span can be shortened and we can reference the other T

error[E0194]: type parameter `T` shadows another type parameter of the same name
  --> src/test/compile-fail/E0194.rs:13:5
   |
11 | trait Foo<T> {
   |           - first `T` declared here
12 |     fn do_something(&self) -> T;
13 |     fn do_something_else<T: Clone>(&self, bar: T); //~ ERROR E0194
   |                          ^ shadows another type parameter

[leikahing]

I'll work on this one.

[leikahing]

@jonathandturner @nikomatsakis I'm working on the bonus portion of this issue but I'm wondering if either of you have any pointers about where to start exploring with manipulating the spans and getting more context out of it so that I can get something that looks like this:

   |
13 |     fn do_something_else<T: Clone>(&self, bar: T); //~ ERROR E0194
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Into this expanded context?

   |
11 | trait Foo<T> {
   |           - first `T` declared here
12 |     fn do_something(&self) -> T;
13 |     fn do_something_else<T: Clone>(&self, bar: T); //~ ERROR E0194

[nikomatsakis]

@birryree any chance we can chat on IRC? :)

[nikomatsakis]

@birryree ok I did a bit of investigating. At the point where error E0194 is issued, we have access to a ty::Generics which in turn contains TypeParameterDef data (in fact, we are iterating over those). These data-structures, like most of ty, is not directly tied to the source (it may for example originate from another crate, for which the source nodes are not available), but -- at least for local nodes -- we can map back to a HIR node (i.e., to the source). We do this by using the field def_id: DefId on the TypeParameterDef. If you have this, you can map a DefId to a NodeId using tcx.map.as_local_node_id(def_id) (it gives you back an Option because the DefId may refer to something from another crate, in general -- but not in this case, so you should be able to just unwrap it). That will give you a NodeId, which is an index into the HIR. You can then use this NodeId to lookup the HIR node by calling tcx.map.find(node_id). This gives you back an Option too (maybe the node-id isn't mapped to anything...), but in this case we expect to find Some(NodeTyParam(ty_param)) (the variant NodeTyParam is defined in rustc::hir::map). The ty_param is a pointer into the HIR, and you can get the span by doing ty_param.span.

Whew!

[leikahing]

@nikomatsakis - Whoa, thanks for the detailed response! Sorry I didn't get back to you sooner - I'm currently headed to a conference. @jonathandturner gave me some pointers over the weekend which helped me get started on the bonus part, so I have been doing some exploration on-and-off into the source to get the steps down for doing what I need.

Your post definitely helps me move in the right direction (I was exploring with tcx.map.span_if_local which seemed like the right way but wasn't quite getting what I wanted).

Thanks again!

[sophiajt]

@birryree - are you still interested in this one? If not, I can release it and let someone else volunteer.

[leikahing]

@jonathandturner Yes, sorry - I already have the changes local, about to make a PR.

[leikahing]

Bonus section is being tracked by #36057 because I wanted to commit the non-bonus part of the update before I committed/made a PR for my additional bonus fixes (as they may require some extra review).