[Refactor] Refactor Flow to use save & restore pattern for handling flow switching

[MaxGraey]

See original proposal in this comment But instead lock / unlock perhaps better to use save / restore names

// save prev flow
const currFlow = this.currentFlow;

currFlow.save();
// Fork and implicitly set this.currentFlow to this fork
var trueBranchFlow = currFlow.toBranch(prevFlow, condExpr, ConditionKind.True);

// do some work with `someFlow`

currFlow.restore(); // release trueBranchFlow's locals and restore previous flow

[HerrCai0907]

But for some complex cases such as doCompileWhileStatement, there are lots of flow. How can we know which flow should be restore and restore what?

[MaxGraey]

Good point. Need to think more. Perhaps save can accept optional argument. Or we can use stack-based approach for save / restore

[dcodeIO]

Or we can use stack-based approach

Indeed, some sort of push/pop for flows seems fitting. Other than that, I am a little skeptical because it restricts what we can do, so we should be reasonably sure that more complicated flow ordering won't be necessary.

[HerrCai0907]

I am a little skeptical because it restricts what we can do, so we should be reasonably sure that more complicated flow ordering won't be necessary.

I think a tree may be suitable for it. Fork some children from parent flow and then go back to the parent

[MaxGraey]

Flow is pretty linear stuff. It can go into deep inner scope, but I don't think we need tree or DAG for handling this