don't use branchCount for extension substack compilation #182
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This fixes a minor parity issue with the interpreter where if the number of SUBSTACK inputs in a block was more than its branchCount (e.g for blocks with mutators), the extra substacks didn't compile.
|
just like last time github won't let me push to this pull request i cherry-picked this into develop, hopefully that still gives you commit credit? |
|
Maybe it doesn't let merging because CSTs fork is a fork of the original scratch VM? |
|
in hindsight i would've been able to just press the merge button instead of cherry-picking since all i had to do was write tests |
actually it may be related to weird git stuff (because i'm making a branch based off of turbowarp on a fork based on vanilla) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Resolves
Resolves 🗨︎(extremely minor parity issue) Compiler uses branchCount for startBranch
Proposed Changes
Makes the compiler use all inputs starting with SUBSTACK for extension C block compilation rather than relying on the block info's branchCount.
Reason for Changes
This fixes a minor parity issue with the interpreter where if the number of SUBSTACK inputs in a block was more than its branchCount (e.g for blocks with mutators), the extra substacks didn't compile.
Test Coverage
Haven't touched tests.