summaryrefslogtreecommitdiff
path: root/testes/locals.lua (follow)
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* First "complete" implementation of to-be-closed variablesRoberto Ierusalimschy2018-10-171-5/+59
| | | | | | | Still missing: - handling of memory errors when creating upvalue (must run closing method all the same) - interaction with coroutines
* Towards "to closed" local variablesRoberto Ierusalimschy2018-10-081-0/+9
| | | | | | | | | | | | Start of the implementation of "scoped variables" or "to be closed" variables, local variables whose '__close' (or themselves) are called when they go out of scope. This commit implements the syntax, the opcode, and the creation of the corresponding upvalue, but it still does not call the finalizations when the variable goes out of scope (the most important part). Currently, the syntax is 'local scoped name = exp', but that will probably change.
* Added directory to test file names in '$Id:'Roberto Ierusalimschy2018-07-251-1/+1
| | | | | | | From the point of view of 'git', all names are relative to the root directory of the project. So, file names in '$Id:' also should be relative to that directory: the proper name for test file 'all.lua' is 'testes/all.lua'.
* Added manual and tests for version 5.4-w2Roberto Ierusalimschy2018-07-091-0/+181