You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ast: the id of a ref pattern conflated; has type T in some contexts and &T in others #18207
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 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.)
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)
Activity
steveklabnik commentedon Oct 27, 2015
@pnkfelix is this issue still valid?
pnkfelix commentedon Oct 27, 2015
@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 commentedon Oct 27, 2015
@pnkfelix
This is semi-going-away with MIR, so not particularly important.
eddyb commentedon Oct 27, 2015
@arielb1 should we have tags for that sort of "fixed-by-MIR" thing?
pnkfelix commentedon Oct 29, 2015
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 commentedon Apr 4, 2017
@pnkfelix still a problem you want fixed?
pnkfelix commentedon Apr 6, 2017
I don't know enough our current lints to judge if it is still a problem, so I will close.
address more FIXME whose associated issues were marked as closed
Auto merge of rust-lang#18207 - mbwilding:master, r=Veykril