Fixing skipAssignment command that wasn't pushing the assignment value when it was expected + test #24
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #23
The old version of skipAssignment systematically popped the value that was going to be assigned, which is right. However, the assignments whose result are used in the next instruction, use a
storeIntobytecode instead of apopIntobytecode. In this case, the assigned value is not popped from the stack. As a consequence, skip should push a value on the stack, as a replacement for the assignment result.To detect if we have a
storeIntobuytecode, I check the number of the current bytecode, which is the first byte of the bytecode, and I compare it to those corresponding tostoreIntobytecode (I looked them up inInstructionStream >> interpretXXXmethods).If the current bytecode is a
storeInto, I push the value of the variable that was going to be assigned as a replacement, because it keeps the same value before and after the assignment is skipped.I also added a test to cover these tricky situations that manipulate both
popIntoandstoreIntobytecode