summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-08-05format with up-to-date rustfmtkyren
2018-08-05very small doc fixeskyren
2018-07-18Upgrade embedded Lua to 5.3.5kyren
2018-06-29(cargo-release) start next development iteration 0.14.1-alpha.0kyren
2018-06-29(cargo-release) version 0.14.0kyren
2018-06-29Prepare for 0.14.0 releasekyren
2018-05-02Fix #78kyren
2018-03-28New approach for ref types, use an auxillary thread stackkyren
Vastly simpler and less magical than using a fixed size magical section of the active stack, and seems to be no slower. The only real downside is that it *seems* extremely extremely hacky (and to be fair, it is).
2018-03-20Nope, require failure 1.0 because otherwise it depends on backtrace ↵kyren
automatically
2018-03-20rely on failure 0.1.2 from git to get backtrace disabled by defaultkyren
without relying on an unreleased 1.0 API. Trying to get rid of the special chucklefish hack branches in the meantime before 1.0.
2018-03-20Use git dependency on failure 1.0 for right nowkyren
2018-03-19Small renames and comments to better communicate the intention of stack ↵kyren
checking functions
2018-03-19Where possible, don't call to_lua / from_lua / to_lua_multi / from_lua_multi ↵kyren
callbacks during Lua stack manipulation This should protect against being able to trigger a stack assert in Lua. Lua and associated types shoul be able to assume that LUA_MINSTACK stack slots are available on any user entry point. In the future, we could turn check_stack into something that only checked the Lua stack when debug_assertions is true.
2018-03-19Always ensure LUA_MINSTACK available stack spaces on callbackkyren
Otherwise, cleanly error with an appropriate stack error. Part of an effort to ensure that it should not be possible to trigger a stack space assert.
2018-03-19Clean up some lifetime specificationkyren
2018-03-12Fix some bad potential unsafety on inner callback calls.kyren
Since we now optionally use stack spaces for handle values, we have to be mindful of whether our stack handle points to the stack in an outer level of Lua "stack protection". We now keep track of the "recursion level" of Lua instances, and do not allow ref manipulation on "outer" Lua instances until the inner callback has returned. Also, update the documentation to reflect the additional panic behavior.
2018-03-12changelog fixeskyren
2018-03-12Use rlua_ asserts instead of unreachable!, changelog updates for 0.14kyren
0.14 will be released alongside `failure` 1.0 with a dependency update.
2018-03-12Fix README mention of "registry handles"kyren
2018-03-12Documentation updates for new handle behavior, and some minor cleanupkyren
2018-03-12Do not crash in release when accessing an AnyUserDatakyren
Also, don't bother asserting if the userdata has no metatable, just behave as though the userdata has no type. This should be impossible to trigger currently without the debug library, but it is not really that useful of an assert anyway.
2018-03-12Move several asserts to only be active with debug, bump alpha version numberkyren
2018-03-12Documentation improvements, split scope into its own module, improved testskyren
Also makes `Lua` and associated types !UnwindSafe and !RefUnwindSafe, which they should be because they are intensely internally mutable. Lua IS still panic safe, but that doesn't mean it should be marked as UnwindSafe (as I understand it).
2018-03-12Remove `stack_guard` function and instead just use StackGuard directlykyren
2018-03-12Add a simple userdata benchmarkkyren
2018-03-12Merge branch 'bench'kyren
2018-03-11A lot of performance changes.kyren
Okay, so this is kind of a mega-commit of a lot of performance related changes to rlua, some of which are pretty complicated. There are some small improvements here and there, but most of the benefits of this change are from a few big changes. The simplest big change is that there is now `protect_lua` as well as `protect_lua_call`, which allows skipping a lightuserdata parameter and some stack manipulation in some cases. Second simplest is the change to use Vec instead of VecDeque for MultiValue, and to have MultiValue be used as a sort of "backwards-only" Vec so that ToLuaMulti / FromLuaMulti still work correctly. The most complex change, though, is a change to the way LuaRef works, so that LuaRef can optionally point into the Lua stack instead of only registry values. At state creation a set number of stack slots is reserved for the first N LuaRef types (currently 16), and space for these are also allocated separately allocated at callback time. There is a huge breaking change here, which is that now any LuaRef types MUST only be used with the Lua on which they were created, and CANNOT be used with any other Lua callback instance. This mostly will affect people using LuaRef types from inside a scope callback, but hopefully in those cases `Function::bind` will be a suitable replacement. On the plus side, the rules for LuaRef types are easier to state now. There is probably more easy-ish perf on the table here, but here's the preliminary results, based on my very limited benchmarks: create table time: [314.13 ns 315.71 ns 317.44 ns] change: [-36.154% -35.670% -35.205%] (p = 0.00 < 0.05) create array 10 time: [2.9731 us 2.9816 us 2.9901 us] change: [-16.996% -16.600% -16.196%] (p = 0.00 < 0.05) Performance has improved. create string table 10 time: [5.6904 us 5.7164 us 5.7411 us] change: [-53.536% -53.309% -53.079%] (p = 0.00 < 0.05) Performance has improved. call add function 3 10 time: [5.1134 us 5.1222 us 5.1320 us] change: [-4.1095% -3.6910% -3.1781%] (p = 0.00 < 0.05) Performance has improved. call callback add 2 10 time: [5.4408 us 5.4480 us 5.4560 us] change: [-6.4203% -5.7780% -5.0013%] (p = 0.00 < 0.05) Performance has improved. call callback append 10 time: [9.8243 us 9.8410 us 9.8586 us] change: [-26.937% -26.702% -26.469%] (p = 0.00 < 0.05) Performance has improved. create registry 10 time: [3.7005 us 3.7089 us 3.7174 us] change: [-8.4965% -8.1042% -7.6926%] (p = 0.00 < 0.05) Performance has improved. I think that a lot of these benchmarks are too "easy", and most API usage is going to be more like the 'create string table 10' benchmark, where there are a lot of handles and tables and strings, so I think that 25%-50% improvement is a good guess for most use cases.
2018-03-11Additional benchmarkskyren
2018-03-11Add some more benchmarkskyren
2018-03-10Use criterion for benchmarking, add some simple benchmarkskyren
2018-03-10Improve documentation about __index vs regular methodskyren
2018-03-08Enable stack leak panic universallykyren
This will potentially panic on Drop of a `Lua` instance, which may be an abort if this is a double panic, but that is more desirable than such a bug being hidden.
2018-03-08Simplify stack_guard / stack_err_guardkyren
The expected change is always zero, because stack_guard / stack_err_guard are always used at `rlua` entry / exit points.
2018-03-08Whoops, fix an assert that was improperly changed to an internal errorkyren
2018-03-08Change strategies for handling the Lua stack during panicskyren
Previously, on an internal panic, the Lua stack would be reset before panicking in an attempt to make sure that such panics would not cause stack leaks or leave the stack in an unknown state. Now, such panic handling is done in stack_guard and stack_err_guard instead, and this is for a few reasons: 1) The previous approach did NOT handle user triggered panics that were outside of `rlua`, such as a panic in a ToLua / FromLua implementation. This is especially bad since most other panics would be indicative of an internal bug anyway, so the utility of keeping `rlua` types usable after such panics was questionable. It is much more sensible to ensure that `rlua` types are usable after *user generated* panics. 2) Every entry point into `rlua` should be guarded by a stack_guard or stack_err_guard anyway, so this should restore the Lua stack on exiting back to user code in all cases. 3) The method of stack restoration no longer *clears* the stack, only resets it to what it previously was. This allows us, potentially, to keep values at the beginning of the Lua stack long term and know that panics will not clobber them. There may be a way of dramatically speeding up ref types by using a small static area at the beginning of the stack instead of only the registry, so this may be important.
2018-03-06README updateskyren
2018-03-06Revert "Temporary fix for #71. Remove when rust #48251 is fixed in stable."kyren
This reverts commit 5d96ddc52a8775092d0aaccf40b34b6a6c56b870.
2018-03-06Update docs to include warning about RegistryKey in callbackskyren
2018-03-06Further safety updates of `protect_lua_call`kyren
Only allow Copy result types and Fn parameter functions, do not risk dropping anything inside function passed to lua_pcall.
2018-03-01Also describe how protect_lua_call functions should not hold types that Dropkyren
2018-03-01Make some changes whose necessity became recently apparent while reading ↵kyren
rustc 1.24.1 change notes. So, despite staring intently at the params structure magic in protect_lua_call, there is still a nasty bug. In the event of an error, the return value of the parameters structure could be dropped despite being mem::unintialized. Of course, the actual return values are incidentally always Copy I think, so this wasn't an actual bug, but I've proven to myself the danger of such dark majyyks. Just use Option and be done with it, it doesn't have to be so complicated! Also document why there are a slew of random functions in the ffi module.
2018-02-28(cargo-release) start next development iteration 0.13.1-alpha.0kyren
2018-02-28Update changelog / cargo.toml in prep for 0.13kyren
2018-02-28Temporary fix for #71. Remove when rust #48251 is fixed in stable.kyren
2018-02-28Add debug API to ffi (not used yet, was using experimentally)kyren
Also fix for cstr! macro
2018-02-19Remove slightly triggering, and now misleading, language from READMEkyren
2018-02-19Remove terrible awful no-good evil hackkyren
The breakage is being addressed in rust itself.
2018-02-19Cleanup max upvalues constant a bit, add some luaconf.h assumptionskyren
2018-02-19Communicate a little bit better about the checkstack constantkyren
2018-02-19Letting scope handles escape the scope was unsafekyren
This simplifies the Scope lifetimes, and should make it a compile error for scope created handles to exit the scope. This should be strictly better, as you would never WANT to do this, but I hope that I have not caused a subtle lifetime problem that would prevent passing those created handles back into Lua. I've tested every situation I can think of, and it doesn't appear to be an issue, but I admit that I don't fully understand everything involved and I could be missing something. The reason that I needed to do this is that if you can let a scope handle escape the scope, you have a LuaRef with an unused registry id, and that can lead to UB. Since not letting the scope references escape is a strict improvement ANYWAY (if I haven't caused a lifetime issue), this is the easiest fix. This is technically a breaking change but I think in most cases if you notice it you would be invoking UB, or you had a function that accepted a Scope or something. I don't know if it's worth a version bump?