Closed adri09070 closed 8 months ago
This is because this array of shared variables is pushed by a bytecode mapped to the node just before the block node, which causes a problem if the block node is the first node to be executed in the first statement, as in that case, the bytecode of interest is bound to the method node, which is the node before the block node. This is a problem because jumpToCaret does not step the method node's bytecodes (and it can't otherwise it would recreate the temp variables and we would lose their value by jumping to caret)
This is a problem because jumpToCaret does not step the method node's bytecodes (and it can't otherwise it would recreate the temp variables and we would lose their value by jumping to caret)
Mmh this looks like we could actually step . From what I see, temps are not created on the method node? It contradicts my analysis from few months ago so I should investigate more.
Anyway, we need to skip the creation of the temp vector at least, I think
Before creating a block, it uses a vector array that is on the stack to share variables with the full block closure that is going to be created.
This array is then popped to create the block closure.
However, if we jump to caret before a block closure creation, it does not push it on the stack:
As a result, when we create the block (by stepping over its creation or jumping into it), it pops the array that is used for the whole context, that has disappeared then. So we can't access the shared variables anymore