ast: the id of a ref pattern conflated; has type T in some contexts and &T in others #18207
Description
Activity
@pnkfelix is this issue still valid?
@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
This is semi-going-away with MIR, so not particularly important.
@arielb1 should we have tags for that sort of "fixed-by-MIR" thing?
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)
@pnkfelix still a problem you want fixed?
- addedT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.P-lowLow priorityLow priority
on Apr 4, 2017 I don't know enough our current lints to judge if it is still a problem, so I will close.
- added a commit that references this issue
on Oct 7, 2017 - added a commit that references this issue
on Oct 8, 2024
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_idto a single type for that node id. However, if you want to know the type of a pattern like theref xin:then you have a problem: are you trying to find the type of the thing that is being borrowed by the match (i.e.
intin this case)? Or are you trying to find the type ofxitself (&intin this case)?The problem is that there is just one
node_idfor the entireref <id>pattern, even though there are two distinct things that you are potentially trying to match.