When we jump to caret to a node inside a block, we go to first pc of the first statement and we skip until the block creation to step it in order to get the created closure. Creating the closure requires to push a temp vector on the stack. This temp vector is not mapped to the AST block, but to the node preceding the block.
If the block creation is the first bytecode in the first statement in the method, then this pushVector bytecode is mapped to the method node. However, we skip all bytecodes mapped to the method node because otherwise it would recreate all temps and that's not what we want when we perform jumpToCaret:.
So, if we perform a jumpToCaret to go into a block that whose creation is the first bytecode in the first statement, then the pushVector bytecode is not executed. As a result, it messes up the stack in both contexts which will ultimately lead to errors.
I fixed this behavior so that, when we go back to the first pc of the first statement, if the associated bytecode is a block creation, I go back to the previous bytecode (which is the pushVector bytecode) to step it to ensure that the stack is correct.
Fixes #55
When we jump to caret to a node inside a block, we go to first pc of the first statement and we skip until the block creation to step it in order to get the created closure. Creating the closure requires to push a temp vector on the stack. This temp vector is not mapped to the AST block, but to the node preceding the block.
If the block creation is the first bytecode in the first statement in the method, then this pushVector bytecode is mapped to the method node. However, we skip all bytecodes mapped to the method node because otherwise it would recreate all temps and that's not what we want when we perform
jumpToCaret:
.So, if we perform a jumpToCaret to go into a block that whose creation is the first bytecode in the first statement, then the pushVector bytecode is not executed. As a result, it messes up the stack in both contexts which will ultimately lead to errors.
I fixed this behavior so that, when we go back to the first pc of the first statement, if the associated bytecode is a block creation, I go back to the previous bytecode (which is the pushVector bytecode) to step it to ensure that the stack is correct.