It can be a little slower, but only for quite large stacks and moreover
stack reallocation is not a common operation. With no strong contrary
reason, it is better to follow the standard.
When computing the Mersenne number, instead of spreading 1's a fixed
number of times (with shifts of 1, 2, 4, 8, 16, and 32), spread only
until the number becomes a Mersenne number.
To avoid complains from some tools, the addition when computing
math.random(n,m), which is computed as n + random(0, m - n), should
use unsigned integers.
New function 'resetCI' resets the CallInfo list of a thread, ensuring
a proper state when creating a new thread, closing a thread, or
closing a state, so that we can run code after that. (When closing a
thread, we need to run its __close metamethods; when closing a
state, we need to run its __close metamethods and its finalizers.)
If a metatable is a weak table, its __newindex field could be collected
by an emergency collection while being used in 'luaV_finishset'. (This
bug has similarities with bug 5.3.2-1, fixed in commit a272fa66.)
This function can be called unprotected, so it should not raise any
kind of errors. (It could raise a memory-allocation error when creating
a message).
Tests for memory-allocation errors moved from 'api.lua' to this new
file, as 'api.lua' was already too big. (Besides, these tests have
nothing to do with the API.)
After a weak table is traversed in the atomic phase, if it does not
have white values ('hasclears') it does not need to be retraversed
again. (Comments were correct, but code did not agree with them.)
Lua can easily overflow an unsigned short counting nested calls.
(The limit to this value is the maximum stack size, LUAI_MAXSTACK,
which is currently 1e6.)
Since commit f407b3c4a, it was being used for two distinct (and
incompatible) meanings:
A: Function has TBC variables (now bit CIST_TBC)
B: Interpreter is closing TBC variables (original bit CIST_CLSRET)
B implies A, but A does not imply B.
Added comments so that all braces pair correctly. (The parser has
several instances of unmatched braces as characters ('{' or '}'), which
hinders matching regular braces in the code.)
The compilation of a goto or a label just create an entry and generate
boilerplate code for the gotos. As we don't know yet whether it needs a
CLOSE, we code a jump followed by a CLOSE, which is then dead code.
When a block ends (and then we know for sure whether there are variables
that need to be closed), we check the goto's against the labels of that
block. When closing a goto against a label, if it needs a CLOSE, the
compiler swaps the order of the jump and the CLOSE, making the CLOSE
active.
Do not optimize only for table updates (key already present).
Creation of new short keys in new tables can be quite common in
programs that create lots of small tables, for instance with
constructors like {x=e1,y=e2}.
Protect stack top before possible stack reallocation. (In the current
implementation, a stack reallocation cannot call an emergency
collection, so there is no bug, but it is safer not to depend on that.)
Moreover, each function being parsed has its own table.
The code is cleaner when each table is used for one specific purpose:
The scanner uses its table to anchor and unify strings, mapping strings
to themselves; the parser uses it to reuse constants in the code,
mapping constants to their indices in the constant table. A different
table for each task avoids false collisions.
