diff options
author | kyren <kerriganw@gmail.com> | 2018-03-12 21:06:31 -0400 |
---|---|---|
committer | kyren <kerriganw@gmail.com> | 2018-03-12 21:06:31 -0400 |
commit | c1e1ac432ca6a7f0ff73d27c791abd8b3647a7a0 (patch) | |
tree | 12d6c68c907d71bc86a2d7867c6a1107aa31891e | |
parent | 1019ab8a3f3260a3db4a65958103647739e0d5e8 (diff) | |
download | mlua-c1e1ac432ca6a7f0ff73d27c791abd8b3647a7a0.zip |
changelog fixes
-rw-r--r-- | CHANGELOG.md | 22 |
1 files changed, 13 insertions, 9 deletions
diff --git a/CHANGELOG.md b/CHANGELOG.md index a40840e..401317f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,10 +1,12 @@ ## [0.14.0] -- Lots of performance improvements, with one major one: Lua handles no longer - necessarily point into the registry, they now can instead point into a - preallocated stack area. All together, you can expect (VERY rough estimate) +- Lots of performance improvements, including one major change: Lua handles no + longer necessarily point into the registry, they now can instead point into a + pre-allocated stack area. All together, you can expect (VERY rough estimate) somewhere on the order of 30%-60% CPU time reduction in the cost of bindings, - depending on usage patterns, but the handle behavior change comes with API - breakage. + depending on usage patterns. +- Addition of some simple criterion.rs based benchmarking. This is the first + `rlua` release to focus on performance, but performance will hopefully remain + a focus going forward. - API incompatible change: Lua handles now must ONLY be used with the `Lua` instance from which they were derived. Before, this would work if both instances were from the same base state, but are now restricted to ONLY the @@ -12,15 +14,17 @@ unsafe code, `Lua::scope`, and things like the `rental` crate which allow self borrowing. For `Lua::scope` functions, you can use `Function::bind`, and for everything else you can use the `RegistryKey` API. -- Several stack size bugfixes that could have lead to unsafety in release mode. - Another API incompatible change: `Lua` (and associated handle values) are no longer `UnwindSafe` / `RefUnwindSafe`. They should not have been marked as such before, because they are *extremely* internally mutable, so this can be considered a bugfix. All `rlua` types should actually be perfectly panic safe as far as *internal* invariants are concerned, but (afaict) they should not be - marked as `UnwindSafe` due to internal mutability and *user* invariants. -- Addition of some simple criterion.rs based benchmarking. -- `rlua` now depends on `failure` 1.0 and `cc` 1.0 + marked as `UnwindSafe` due to internal mutability and thus potentially + breaking *user* invariants. +- Several Lua stack checking bugs have been fixed that could have lead to + unsafety in release mode. +- `rlua` now depends on `failure` 1.0 and `cc` 1.0, and does not enable the + failure `backtrace` feature by default. ## [0.13.0] - Small API incompatible change which fixes unsafety: Scope and scope created |