When closing variables during 'coroutine.close' or 'lua_resetthread',
the status of a coroutine must be set to LUA_OK; a coroutine should
not run with any other status. (See assertion in 'lua_callk'.)
After the reset, the status should be kept as normal, as any error
was already reported.
More uses of macros 'likely'/'unlikely' (renamed to
'l_likely'/'l_unlikely'), both in range (extended to the
libraries) and in scope (extended to hooks, stack growth).
Allow memory errors to be raised through the API (throwing the
error with the memory error message); error in external allocations
raises a memory error; memory errors in coroutines are re-raised
as memory errors.
When there are multiple errors when closing objects, the error
reported by the protected call is the first one, for two reasons:
First, other errors may be caused by this one;
second, the first error is handled in the original execution context,
and therefore has the full traceback.
Back to how it was, a coroutine does not unwind its stack in case of
errors (and therefore do not close its to-be-closed variables). This
allows the stack to be examined after the error. The program can
use 'coroutine.kill' to close the variables.
The function created by 'coroutine.wrap', however, closes the
coroutine's variables in case of errors, as it is impossible to examine
the stack any way.
New functions to reset/kill a thread/coroutine, mainly (only?) to
close any pending to-be-closed variable. ('lua_resetthread' also
allows a thread to be reused...)
New auxiliary functions/macros 'luaL_argexpected'/'luaL_typeerror'
ease the creation of error messages such as
bad argument #2 to 'setmetatable' (nil or table expected, got boolean)
(The novelty being the "got boolean" part...)
themselves with 'require' (let 'require' do its work); new auxiliary
functions luaL_newlib/luaL_newlibtable/luaL_setfuncs/luaL_requiref.
Old luaL_register will be deprecated.
Roberto Ierusalimschy