Confusing error if accidentially defining a type paramter with the same name as an existing type

[Kimundi]

An example from IRC just now:

https://play.rust-lang.org/?gist=ad253f7f1b851935890346136fe47912&version=stable&mode=debug&edition=2015

#[derive(Debug)]
struct Point
{
    x: i32,
    y: i32
}

impl Point
{
    fn add(a: &Point, b: &Point) -> Point
    {
        Point {x: a.x + b.x, y: a.y + b.y}
    }
}

trait Eq
{
    fn equals<T>(a: &T, b: &T) -> bool;
}

impl Eq for Point
{
    fn equals<Point>(a: &Point, b: &Point) -> bool
    {
        a.x == b.x && a.y == b.y
    }
}

fn main()
{
    let p1 = Point {x:  0, y: 10};
    let p2 = Point {x: 20, y: 42};
    println!("{:?}", Point::add(&p1, &p2));
    println!("p1: {:?}, p2: {:?}", p1, p2);
    println!("p1 == p2: {:?}", Eq::equals(&p1, &p2));
}

   Compiling playground v0.0.1 (file:///playground)
error[E0609]: no field `x` on type `&Point`
  --> src/main.rs:25:11
   |
25 |         a.x == b.x && a.y == b.y
   |           ^

error[E0609]: no field `x` on type `&Point`
  --> src/main.rs:25:18
   |
25 |         a.x == b.x && a.y == b.y
   |                  ^

error[E0609]: no field `y` on type `&Point`
  --> src/main.rs:25:25
   |
25 |         a.x == b.x && a.y == b.y
   |                         ^

error[E0609]: no field `y` on type `&Point`
  --> src/main.rs:25:32
   |
25 |         a.x == b.x && a.y == b.y
   |                                ^

error: aborting due to 4 previous errors

For more information about this error, try `rustc --explain E0609`.
error: Could not compile `playground`.

To learn more, run the command again with --verbose.

The mistake here is that Point is also used as a shadowing type parameter inside the Function.

Maybe have a warn lint that tries to detect cases like this? (With a type parameter that also exist as a concrete type in the surrounding scope)

This issue has been assigned to @Baranowski via this comment.

[oli-obk]

Clippy has such a lint, but it would trigger after the errors I think. We could mention that something is a type parameter whenever errors related to it occur. Or have a lint at resolve time

[estebank]

E0609 should point at the type that doesn't have the field, in this case it would point at the type argument and not the struct, making it easier to figure out what's happening.

[estebank]

The cases TyParam and TyRef need to be handled in

rust/src/librustc_typeck/check/expr.rs

Line 1437 in f7af19c

_ => {}

for the former by doing something like

let parent_id = self.tcx.hir().get_parent_item(expr.hir_id);
let parent = self.tcx.hir().get(parent_id);

and finding the appropriate param name and use its span to point to. For the TyRef case it's slightly harder because you need to dereference to find if it is an ADT or a Param, but the same rules apply.

[Baranowski]

I would like to work on this as I'm currently learning Rust, if you don't mind.

[oli-obk]

Great! you can reserve this issue via @rustbot claim

[Baranowski]

@rustbot claim

[Baranowski]

I would appreciate some hand-holding here.

From check_field, I have access to ty::ParamTy. It seems that if I also had ty::Generics available, I could map ty::ParamTy to ty::GenericParamDef, extract DefId from that, and get a step closer to span (which I suspect is stored somewhere in hir::). Perhaps I should add ty::Generics to rustc_typeck::check::FnCtxt?

[oli-obk]

The self object has a body_id field which should allow you to get at the DefId (I think tcx.hir().body_owner_def_id(self.body_id)) which you can then use with tcx.generics_of

[Baranowski]

I believe this issue can now be closed.