lua/ldo.c, branch v5.5.1A mirror of https://github.com/lua/lua
https://git.lua4.win/lua/atom?h=v5.5.12026-06-03T14:58:39+00:00Removed unused function 'luaD_inctop'2026-06-03T14:58:39+00:00Roberto Iroberto@inf.puc-rio.br2026-06-03T14:58:39+00:00urn:sha1:40b76de2d77e66b70a9d4bf989c3f5340919973f
Commit 3228a97 removed all its uses.
new macro 'setnilvalue2s'2026-04-23T21:00:23+00:00Roberto Iroberto@inf.puc-rio.br2026-04-23T21:00:23+00:00urn:sha1:ae23e726018bd31a25c1279600328d90207ec81cBug: 'lua_load' does not preserve the stack2026-04-23T20:57:42+00:00Roberto Iroberto@inf.puc-rio.br2026-04-23T20:57:42+00:00urn:sha1:3228a97c6a953dcf397944161bb64b12f1ff5384
'lua_load' does not preserve the stack through the calls to the
reader function, as it should. Immediately after the first call (to
detect whether chunk is binary) it adds stuff, and it also adds a new
table when starting the compilation of each new function.
More effort in avoiding errors in finalizers2026-01-11T18:36:03+00:00Roberto Iroberto@inf.puc-rio.br2026-01-11T18:36:03+00:00urn:sha1:2a7cf4f319fc276f4554a8f6364e6b1ba4eb2ded
Before calling a finalizer, Lua not only checks stack limits, but
actually ensures that a minimum number of slots are already allocated
for the call. (If it cannot ensure that, it postpones the finalizer.)
That avoids finalizers not running due to memory errors that the
programmer cannot control.
GC checks stack space before running finalizer2025-12-13T19:16:59+00:00Roberto Iroberto@inf.puc-rio.br2025-12-13T19:16:59+00:00urn:sha1:a5522f06d2679b8f18534fd6a9968f7eb539dc31
If the stack does not have some minimum available space, the GC defers
calling a finalizer until the next cycle. That avoids errors while
running a finalizer that the programmer cannot control.
Functions with vararg tables don't need hidden args.2025-11-28T18:12:51+00:00Roberto Iroberto@inf.puc-rio.br2025-11-28T18:12:51+00:00urn:sha1:a07f6a824197d7dc01c321599d3bc71936a2590e
Vararg functions with vararg tables don't use the arguments hidden in
the stack; therfore, it doesn't need to build/keep them.
In C++, 'throw' must go to the correct handler.2025-09-05T18:29:15+00:00Roberto Iroberto@inf.puc-rio.br2025-09-05T18:29:15+00:00urn:sha1:ffbcadfb4197213d55222bca3ecc52606cd980f4
In C, we may have several "setjmp" nested, and the "longjmp" will go
to the one given by the corresponding "jmp_buf". In C++, a "throw"
will always go to the inner "catch". So, the "catch" must check
whether it is the recipient of the "throw" and, if not, rethrow
the exception to the outer level.
Better documentation for LUA_ERRERR2025-08-20T18:29:46+00:00Roberto Iroberto@inf.puc-rio.br2025-08-20T18:29:46+00:00urn:sha1:c345877e4c2588324d9a1e5655e8f48200ba2e5e
Not all errors in a message handler generate a LUA_ERRERR.
LUAI_MAXSTACK defined privately2025-07-01T13:57:02+00:00Roberto Ierusalimschyroberto@inf.puc-rio.br2025-07-01T13:57:02+00:00urn:sha1:59a1adf194efe43741c2bb2005d93d8320a19d14
LUAI_MAXSTACK is limited to INT_MAX/2, so can use INT_MAX/2 to define
pseudo-indices (LUA_REGISTRYINDEX) in 'lua.h'. A change in the maximum
stack size does not need to change the Lua-C ABI.
A coroutine can close itself2025-06-12T14:15:09+00:00Roberto Ierusalimschyroberto@inf.puc-rio.br2025-06-12T14:15:09+00:00urn:sha1:fd897027f19288ce2cb0249cb8c1818e2f3f1c4c
A call to close itself will close all its to-be-closed variables and
return to the resume that (re)started the coroutine.