Use rlua_ asserts instead of unreachable!, changelog updates for 0.14
0.14 will be released alongside `failure` 1.0 with a dependency update.
This commit is contained in:
parent
c252668ba6
commit
1019ab8a3f
24
CHANGELOG.md
24
CHANGELOG.md
|
@ -1,3 +1,27 @@
|
|||
## [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)
|
||||
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.
|
||||
- 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
|
||||
matching `Lua` instance itself. This was previously only possible through
|
||||
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
|
||||
|
||||
## [0.13.0]
|
||||
- Small API incompatible change which fixes unsafety: Scope and scope created
|
||||
handle lifetimes have been changed to disallow them from escaping the scope
|
||||
|
|
|
@ -721,7 +721,7 @@ impl Lua {
|
|||
|
||||
ffi::LUA_TTHREAD => Value::Thread(Thread(self.pop_ref())),
|
||||
|
||||
_ => unreachable!("internal error: LUA_TNONE in pop_value"),
|
||||
_ => rlua_panic!("LUA_TNONE in pop_value"),
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -1157,8 +1157,7 @@ impl Lua {
|
|||
let mut args = MultiValue::new();
|
||||
args.reserve(stack_nargs as usize);
|
||||
|
||||
// First, convert all of the reference types in the ref stack area into LuaRef types
|
||||
// in-place.
|
||||
// Convert all of the reference types in the ref stack area into LuaRef types in-place.
|
||||
for i in 0..stack_nargs {
|
||||
let n = stack_nargs - i;
|
||||
|
||||
|
@ -1215,7 +1214,7 @@ impl Lua {
|
|||
args.push_front(Value::Thread(Thread(make_ref())));
|
||||
}
|
||||
|
||||
_ => unreachable!("internal error: LUA_TNONE in pop_value"),
|
||||
_ => rlua_panic!("LUA_TNONE in setup_callback_stack_slots"),
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -1232,7 +1231,6 @@ impl Lua {
|
|||
extra_args.push(self.pop_value());
|
||||
}
|
||||
extra_args.extend(args.into_vec_rev());
|
||||
|
||||
MultiValue::from_vec_rev(extra_args)
|
||||
} else {
|
||||
args
|
||||
|
|
Loading…
Reference in New Issue