Control flow analysis

[farodin91]

Possible parts:

• Type inference/checking
• Control flow graph building Control flow graph implementation #2687
• Borrow checker
  • Move analysis Borrow checker (move analysis) #2810
  • Use of uninitialized variable detection Add "Use of uninitialized variable" diagnostic #3315
  • Borrow analysis (at least False negative: borrow of moved value #5148)
  • Moves and borrows visualization (e.g. Feature Request: Style methods differently depending on if they take self, &self or &mut self. #2794)
• Liveness analysis (dead code detection) Liveness analysis #3163
• Redundant mutability detection Variable can be immutable intention #1004
• Unreachable code detection INSP: Implement unreachable code detection #6829
• Process control flow of blocks and closures inside constant declarations (e.g. static X: i32 = { ... })

[vlad20012]

I think we should perform type checking (and possibly all of the above) during type inference and save errors into RsInferenceContext (as mapping like expr => error). Then extract errors from the context by an error annotator. But I do not think that we can do any type checking right now. Currently I'm working on something called Expectation, and after implementing it, it should be possible to perform some limited type checking.

[matklad]

@vlad20012 we also need a limited form of control flow analysis in type inference, to deal with ! type properly: #1599