aboutsummaryrefslogtreecommitdiff
path: root/testes/locals.lua (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Avoid excessive name pollution in test filesRoberto Ierusalimschy2022-12-281-3/+5
| | | | | Test files are more polite regarding the use of globals when locals would do, and when globals are necessary deleting them after use.
* Bug: 'break' may not properly close variable in a 'for' loopRoberto Ierusalimschy2022-08-241-0/+20
| | | | | | | Function 'leaveblock' was generating "break" label before removing variables from the closing block. If 'createlabel' created a 'close' instruction (which it did when matching a goto/break that exited the scope of an upvalue), that instruction would use the wrong level.
* Bug: 'lua_settop' may use an invalid pointer to stackRoberto Ierusalimschy2022-05-251-0/+22
|
* Bug: 'local function' can assign to '<const>' variablesRoberto Ierusalimschy2021-06-201-0/+2
|
* Bug: yielding in '__close' mess up number of returnsRoberto Ierusalimschy2021-04-161-0/+59
| | | | | Yielding in a __close metamethod called when returning vararg results changes the top and so messes up the number of returned values.
* Bug: tbc variables in "for" loops don't avoid tail callsRoberto Ierusalimschy2021-04-071-0/+23
|
* New test module 'tracegc'Roberto Ierusalimschy2021-03-011-2/+4
| | | | New module easies the inclusion of GC tracing in individual test files.
* '__close' methods can yield in the return of a C functionRoberto Ierusalimschy2021-02-121-1/+75
| | | | | | | When, inside a coroutine, a C function with to-be-closed slots return, the corresponding metamethods can yield. ('__close' metamethods called through 'lua_closeslot' still cannot yield, as there is no continuation to go when resuming.)
* New implementation for to-be-closed variablesRoberto Ierusalimschy2021-02-091-8/+41
| | | | | | | | To-be-closed variables are linked in their own list, embedded into the stack elements. (Due to alignment, this information does not change the size of the stack elements in most architectures.) This new list does not produce garbage and avoids memory errors when creating tbc variables.
* Correct order of return hooks vs. close metamethodsRoberto Ierusalimschy2021-01-211-7/+70
| | | | | | The return hook should be called only after closing variables (which are still part of the function). C functions were calling the hook before the metamethods.
* Simpler handling of errors when creating tbc variablesRoberto Ierusalimschy2021-01-191-8/+5
| | | | | | New field 'lua_State.ptbc' keeps to-be-closed variable until its upvalue is created, so that it can be closed in case of a memory-allocation error.
* Allow yields in '__close' metamethods ater errorsRoberto Ierusalimschy2021-01-181-8/+40
| | | | | | Completes commit b07fc10e91a. '__close' metamethods can yield even when they are being called due to an error. '__close' metamethods from C functions are still not allowed to yield.
* Allow yields inside '__close' metamethodsRoberto Ierusalimschy2021-01-131-0/+88
| | | | | | | Initial implementation to allow yields inside '__close' metamethods. This current version still does not allow a '__close' metamethod to yield when called due to an error. '__close' metamethods from C functions also are not allowed to yield.
* Better error messages for calling non-callable objectsRoberto Ierusalimschy2020-12-291-1/+16
| | | | | | | When available, use the calling code to find a suitable name for what was being called; this is particularly useful for errors of non-callable metamethods. This commit also improved the debug information for order metamethods.
* No need to recheck close method before calling itRoberto Ierusalimschy2020-12-291-2/+44
| | | | | | | | A to-be-closed variable is constant and it must have a close metamethod when it is created. A program has to go out of its way (e.g., by changing the variable's metamethod) to invalidate that check. So, it is not worth to test that again. If the program tampers with the metamethod, Lua will raise a regular error when attempting to call it.
* Report last error in closing methodsRoberto Ierusalimschy2020-12-221-75/+24
| | | | | When there are multiple errors around closing methods, report the last error instead of the original.
* Upvalues removed from 'openupval' before being closedRoberto Ierusalimschy2020-12-211-17/+9
| | | | | | | Undo commit c220b0a5d0: '__close' is not called again in case of errors. (Upvalue is removed from the list before the call.) The common error that justified that change was C stack overflows, which are much rarer with the stackless implementation.
* 'coroutine.close'/'lua_resetthread' report original errorsRoberto Ierusalimschy2020-12-181-8/+15
| | | | | | Besides errors in closing methods, 'coroutine.close' and 'lua_resetthread' also consider the original error that stopped the thread, if any.
* DetailsRoberto Ierusalimschy2020-10-121-0/+23
| | | | | | | - After converting a generic GCObject to a specific type ('gco2*'), avoid using the original GCObject (to reduce aliasing). - Small corrections in comments in 'lopcodes.h' - Added tests about who calls __close metamethods
* Avoid memory allocation in some functions from 'ltests.c'Roberto Ierusalimschy2020-07-041-2/+2
| | | | | | | To allow their use in memory tests, some functions in 'ltests.c' should never allocate memory. To avoid this allocation, the library registers the strings used for status codes, and keeps the variable '_WARN' always defined (with false instead of nil).
* Fixed two bugs in to-be-closed variables x constantsRoberto Ierusalimschy2020-06-011-0/+37
| | | | | | | | | | The parser were mixing compiler indices of variables with stack indices, so that when a to-be-closed variable was used inside the scope of compile-time constants (which may be optimized away), it might be closed in the wrong place. (See new tests for examples.) Besides fixing the bugs, this commit also changed comments and variable names to avoid that kind of confusion and added tests.
* Comments (mosty typos)Roberto Ierusalimschy2019-12-301-1/+1
|
* Subtraction of small constant integers optimized with OP_ADDIRoberto Ierusalimschy2019-09-241-1/+1
|
* Default for warnings changed to "off"Roberto Ierusalimschy2019-08-201-0/+1
| | | | | Warnings are mostly a tool to help developers (e.g., by showing hidden error messages); regular users usually don't need to see them.
* Improvement in warn-mode '@store' (for testing)Roberto Ierusalimschy2019-08-181-14/+21
| | | | | | When using warn-mode '@store', from the test library, the tests ensure not only that the expected warnings were issued, but also that there was no extra warnings.
* Supressed errors in '__close' generate warningsRoberto Ierusalimschy2019-08-161-25/+127
|
* Tracebacks recognize metamethods '__close'Roberto Ierusalimschy2019-07-311-4/+17
|
* To-be-closed variables must be closed on initializationRoberto Ierusalimschy2019-07-311-11/+12
| | | | | | | | | When initializing a to-be-closed variable, check whether it has a '__close' metamethod (or is a false value) and raise an error if if it hasn't. This produces more accurate error messages. (The check before closing still need to be done: in the C API, the value is not constant; and the object may lose its '__close' metamethod during the block.)
* Change in the syntax of attributesRoberto Ierusalimschy2019-07-301-35/+35
| | | | | | | Attributes changed to posfixed ('x <const>', instead of '<const> x'), and "toclose" renamed to "close". Posfixed attributes seem to make it clearer that it applies to only one variable when there are multiple variables.
* '__close' method may be called again in case of errorRoberto Ierusalimschy2019-07-161-7/+14
| | | | | | | | | An error in a closing method may be caused by a lack of resources, such as memory or stack space, and the error may free enough resources (by unwinding the stack) to allow the method to work if called again. If the closing method is already running after some error (including its own), it is not called again.
* First implementation of constant propagationRoberto Ierusalimschy2019-07-121-1/+1
| | | | | Local constant variables initialized with compile-time constants are optimized away from the code.
* New implementation for constantsRoberto Ierusalimschy2019-07-091-4/+14
| | | | | | | | | VLOCAL expressions keep a reference to their corresponding 'Vardesc', and 'Upvaldesc' (for upvalues) has a field 'ro' (read-only). So, it is easier to check whether a variable is read-only. The decoupling in VLOCAL between 'vidx' ('Vardesc' index) and 'sidx' (stack index) should also help the forthcoming implementation of compile-time constant propagation.
* Local attributes can be used in list of local variablesRoberto Ierusalimschy2019-07-031-6/+28
| | | | | | | | | | | | The syntax for local attributes ('const'/'toclose') was unified with the regular syntax for local variables, so that we can have variables with attributes in local definitions with multiple names; for instance: local <toclose> f, <const> err = io.open(fname) This new syntax does not implement constant propagation, yet. This commit also has some small improvements to the manual.
* Details in testsRoberto Ierusalimschy2019-06-211-18/+6
| | | | | | | | | | - Added a test for calling 'debug.traceback' after yields inside hooks. (Lua 5.3 seems to have a bug there.) - Removed test "repeat test with '__open' metamethod instead of a function", as the previous test already uses the '__open' metamethod. (It changed when functions were removed as possible to-be-closed variables).
* Multiple errors in '__toclose' report the first oneRoberto Ierusalimschy2019-06-051-13/+24
| | | | | | | | 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.
* bug in 5.4 alpha rc1: to-be-closed x vararg functionsRoberto Ierusalimschy2019-06-031-0/+9
| | | | | | Closing methods must be run before correcting 'ci->func' when exiting a vararg function, to get correct debug information (e.g., in case of errors).
* DetailsRoberto Ierusalimschy2019-05-281-1/+0
| | | | | | | - new error message for "attempt to assign to const variable" - note in the manual about compatibility options - comments - small changes in 'read_line' and 'pushstr'
* Flag for to-be-closed variables changed to '<toclose>'Roberto Ierusalimschy2019-05-091-25/+25
| | | | | | | The flag for to-be-closed variables was changed from '*toclose' to '<toclose>'. Several people found confusing the old syntax and the new one has a clear terminator, making it more flexible for future changes.
* Coroutines do not unwind the stack in case of errorsRoberto Ierusalimschy2019-05-091-8/+27
| | | | | | | | | | | 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.
* No more to-be-closed functionsRoberto Ierusalimschy2019-01-041-23/+31
| | | | | | | | | | | | | | | | | | | To-be-closed variables must contain objects with '__toclose' metamethods (or nil). Functions were removed for several reasons: * Functions interact badly with sandboxes. If a sandbox raises an error to interrupt a script, a to-be-closed function still can hijack control and continue running arbitrary sandboxed code. * Functions interact badly with coroutines. If a coroutine yields and is never resumed again, its to-be-closed functions will never run. To-be-closed objects, on the other hand, will still be closed, provided they have appropriate finalizers. * If you really need a function, it is easy to create a dummy object to run that function in its '__toclose' metamethod. This comit also adds closing of variables in case of panic.
* Calls cannot be tail in the scope of a to-be-closed variableRoberto Ierusalimschy2018-12-041-5/+8
| | | | | | A to-be-closed variable must be closed when a block ends, so even a 'return foo()' cannot directly returns the results of 'foo'; the function must close the scope before returning.
* A to-be-closed variable must have a closable value (or be nil)Roberto Ierusalimschy2018-11-291-0/+21
| | | | | | | It is an error for a to-be-closed variable to have a non-closable non-nil value when it is being closed. This situation does not seem to be useful and often hints to an error. (Particularly in the C API, it is easy to change a to-be-closed index by mistake.)
* Auxiliary buffer cannot close box with 'lua_remove'Roberto Ierusalimschy2018-11-261-16/+40
| | | | | | | To remove a to-be-closed variable from the stack in the C API a function must use 'lua_settop' or 'lua_pop'. Previous implementation of 'luaL_pushresult' was not closing the box. (This commit also added tests to check that box is being closed "as soon as possible".)
* String buffer using to-be-closed variableRoberto Ierusalimschy2018-11-131-0/+32
| | | | | The string buffers in the C API now mark their boxes as to-be-closed variables, to release their buffers in case of errors.
* To-be-closed variable in 'for' loop separated from the stateRoberto Ierusalimschy2018-11-071-1/+7
| | | | | | | | | The variable to be closed in a generic 'for' loop now is the 4th value produced in the loop initialization, instead of being the loop state (the 2nd value produced). That allows a loop to use a state with a '__toclose' metamethod but do not close it. (As an example, 'f:lines()' might use the file 'f' as a state for the loop, but it should not close the file when the loop ends.)
* New syntax for to-be-closed variablesRoberto Ierusalimschy2018-11-071-21/+21
| | | | | | | The new syntax is <local *toclose x = f()>. The mark '*' allows other attributes to be added later without the need of new keywords; it also allows better error messages. The API function was also renamed ('lua_tobeclosed' -> 'lua_toclose').
* State in generic 'for' acts as a to-be-closed variableRoberto Ierusalimschy2018-10-311-1/+49
| | | | | | | | | | | The implicit variable 'state' in a generic 'for' is marked as a to-be-closed variable, so that the state will be closed as soon as the loop ends, no matter how. Taking advantage of this new facility, the call 'io.lines(filename)' now returns the open file as a second result. Therefore, an iteraction like 'for l in io.lines(name)...' will close the file even when the loop ends with a break or an error.
* Closing methods should not interfere with returning valuesRoberto Ierusalimschy2018-10-251-1/+54
| | | | | | | | | | | | A closing method cannot be called in its own stack slot, as there may be returning values in the stack after that slot, and the call would corrupt those values. Instead, the closing method must be copied to the top of the stack to be called. Moreover, even when a function returns no value, its return istruction still has to have its position (which will set the stack top) after the local variables, otherwise a closing method might corrupt another not-yet-called closing method.
* Complete implementation of to-be-closed variablesRoberto Ierusalimschy2018-10-221-4/+29
|
* Handling of memory errors when creating to-be-closed upvaluesRoberto Ierusalimschy2018-10-181-6/+52
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-16 22:58:45 +0000