You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a variable is both assigned and read inside a multiple assignment, Lua ensures that all reads get the value of the variable before the assignment.
Note that this guarantee covers only accesses syntactically inside the assignment statement. If a function or a metamethod called during the assignment changes the value of a variable, Lua gives no guarantees about the order of that access.
It looks like the issue is in Compiler::assignment_statement, which currently generates a sequence of assignments, interleaving the evaluation and assignment. The simple fix would be to evaluate the RHS expressions into temporaries before evaluating the assignments, but handling varargs expressions will be more complex. (In addition, this relies on optimization passes to remove the unnecessary register moves.)
The issue is not limited to table assignments, as it also occurs with locals:
localx, y=1, 2x, y=y, xprint(x, y) -- 2, 2
Bytecode:
0: OpCode(LoadConstant { dest: RegisterIndex(0), constant: ConstantIndex16(0) }) # x = 1
1: OpCode(LoadConstant { dest: RegisterIndex(1), constant: ConstantIndex16(1) }) # y = 2
2: OpCode(Move { dest: RegisterIndex(0), source: RegisterIndex(1) }) # x = y
3: OpCode(Move { dest: RegisterIndex(2), source: RegisterIndex(0) }) # temp = x
4: OpCode(Move { dest: RegisterIndex(1), source: RegisterIndex(2) }) # y = temp
In PRLua, the evaluation order appears to be left-to-right for the values, and then right-to-left for the assignments; logging the operations in the following code:
t[4], t[5], t[6] =t[2], t[1], nil
index 2
index 1
newindex 6 nil
newindex 5 1
newindex 4 2
The following lua script:
fails in latest piccolo fcbaabc
the table contains
2,2
instead of2,1
The text was updated successfully, but these errors were encountered: