Open
Description
The current liveness code does a simple liveness computation (actually a few such things) and tells you when e.g. assignments are dead and that sort of thing. It does this on the HIR. It would be better to do this on the MIR — in fact, the NLL computation is already computing liveness across all of MIR, so we ought to be able to piggy back on those results I imagine.
It may be a good idea to wait though until the MIR borrowck stuff "settles down" a bit before attempting this.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Participants
Activity
LiveNode. #50981region_live_atfacts rust-lang/polonius#61nikomatsakis commentedon Jul 3, 2018
I'm removing WG-compiler-nll as this isn't really related to NLL, it's just general cleanup. Here are some tips into the code for future reference:
The liveness code I am referring to, which ought to be ported:
rust/src/librustc/middle/liveness.rs
Line 190 in 860d169
The MIR-based liveness computation:
rust/src/librustc_mir/util/liveness.rs
Line 118 in 860d169
rustc_passes::livenessto MIR #68419cjgillot commentedon Feb 13, 2020
Is this issue still relevant? Can I pick it up?
matthewjasper commentedon Feb 13, 2020
It's still relevant. Feel free to ping me with questions.
ecstatic-morse commentedon May 10, 2020
I looked into this this morning. A few roadblocks remain.
For one, the MIR has no record of statements like
let _ = xeven beforeSimplifyCfg. More complex expressions seem to be lowered even when they are assigned to_, so I think the solution is to look for an assignment of anExprKind::VarRefspecifically and lower it to aFakeReadof some kind.There's also the issue of associating
Locals with theirHirIds for diagnostics. This was attempted in #51275, but it caused issues with incremental compilation. That PR worked around the issue by computing the spans needed for MIR borrowck errors ahead-of-time. I think a better solution would be to stop includingVarBindingInfoin theStableHashof a MIR body. I don't fully understand the implications of ignoringVarBindingInfofor the purposes of incremental. I think it's okay as long as we don't use theHirIdto determine whether to emit a lint/error, only to associate it with aSpan. This suggests that we need to precompute the level for the "unused variables" lint. Alternatively, we could duplicate the approach in #51275, but that won't scale as more checking is moved to the MIR.Finally, I was seeing spurious warnings for variables that were bound in a match arm and only used in a guard. Presumably this will also require some changes to MIR building, but I've not investigated this one yet.
Since I don't have a good intuition for incremental compilation or MIR building, I would appreciate any advice on solving either of these problems. @pnkfelix, this was a while ago, but did you consider ignoring
VarBindingInfoduring stable hashing in #51275?31 remaining items