delta/mlua
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

changelog fixes

Browse source
This commit is contained in:
kyren 2018-03-12 21:06:31 -04:00
parent 1019ab8a3f
commit c1e1ac432c
1 changed files with 13 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
CHANGELOG.md
View file

@ -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