Issue #514 : Fix compileRegAssignment cardinality #528
Conversation
This file contains hidden or 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
Use `nvars` as the assignment numbers rather than `lennames`. This makes no difference in `compileLocalAssignStmt` as the numbers are equal, but in `compileGenericForStmt` the names are the iteration variables while `nvars` refers to the local generator, state, and control. The iteration variables feel a bit out of place here. The whole body of `compileRegAssignment` seem inconsistent, using `names` only for its length, and mixing `lennames` and `nvars` in surprising ways. Moreover the function name `compileRegAssignment` suggests assigning to registers rather than names, so I dropped `lennames` entirely to use only `nvars`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 #514
Changes proposed in this pull request:
compileRegAssignment, usenvarsas the assignment cardinality rather thanlennames.namesargumentI don't really know what I'm doing, I just tried to infer what things were supposed to be doing based on their names. I started with the test case filed in #514 and compared with the behavior of official Lua 5.1. It turned out that
luachas extraLOADNILwhich reset the registers that weren't correctly reset by gopher-lua, so I poked aroundcompileGenericForStmtand it took me a while to understand why the iteration variable names were fed tocompileRegAssignmentwhen its place in the code and the other arguments suggested it should be about initializing internal generator/state/control triplet rather than iteration variables.I checked that after this change, the opcodes generated by gopher-lua are similar to those from luac, and the whole test suite passes.