ast: the id of a ref pattern conflated; has type `T` in some contexts and `&T` in others

[pnkfelix]

While working on my follow-up to #17439 I rediscovered an old problem in our ast representation:

We usually act like you can unambiguously map a node_id to a single type for that node id. However, if you want to know the type of a pattern like the ref x in:

let t = Some(box 3i);
match t {
  Some(ref x) => ...,
  None => ...,
}

then you have a problem: are you trying to find the type of the thing that is being borrowed by the match (i.e. int in this case)? Or are you trying to find the type of x itself (&int in this case)?

The problem is that there is just one node_id for the entire ref <id> pattern, even though there are two distinct things that you are potentially trying to match.

[steveklabnik]

@pnkfelix is this issue still valid?

[pnkfelix]

@steveklabnik IMO it still is an issue. Its something internal to the compiler, but I wouldn't be surprised if it is a source of bugs (either old or new.)

cc @rust-lang/compiler

[arielb1]

@pnkfelix

This is semi-going-away with MIR, so not particularly important.

[eddyb]

@arielb1 should we have tags for that sort of "fixed-by-MIR" thing?

[pnkfelix]

Hmm I will need to review the MIR RFC ... while I understand that some analyses will be applicable to the MIR (and indeed, some of those will solely apply to MIR then, no more AST inputs), for some reason I assumed that we would still do some amount of type-related computations on the AST form. (Why did I think this? I guess mostly for lints that want type info... Or will those all be ported to operate on MIR somehow? Doesn't sound very linty at that point)

[brson]

@pnkfelix still a problem you want fixed?

[pnkfelix]

I don't know enough our current lints to judge if it is still a problem, so I will close.