Credit to @eeckstein for noticing this possibility
I considered some much more complicated solutions to this problem, like
tracking all the deallocations we add and remove and then undoing them
for the allocations we end up marking non_nested, but ultimately I
figured out that this would work and was much less invasive, even if it
potentially yields slightly worse results in some cases.
Specifically:
1. We were tracking the stack allocation both in handleScopeInst and in the
Stack. We should only track it in one of them. I also used this as an
opportunity to make sure the code worked for non_nested code.
2. I made it so that we properly handle the end tracking part of the code so we
handle the token/stack part of begin_apply correctly. I generalized the code so
that we should handle non_nested stack allocations as well.
I included tests that validated that we now handle this correctly.
else-if chains provide the possibility that there is additional code after the
else-if chain. In this case, no such code exists, so by using early continues we
communicate that the iteration ends at the end of an if block and the programmer
does not need to read to the end of the else-if block.
This also allows for me to eliminate one level of indentation in the successor
code as well.
This has grown large enough and complex enough that it makes sense to go into
its own file.
This is a NFCI change. The only substantial changes is I added a small require
impl based on the one in SILVerifier and I eliminated the namespace
VerifyFlowSensitiveRulesDetails.
John McCall
Michael Gottesman