2017-10-23 16:42:20 -04:00
|
|
|
use std::collections::{BTreeMap, HashMap};
|
2017-10-24 16:15:57 -04:00
|
|
|
use std::hash::{BuildHasher, Hash};
|
2017-07-20 05:33:15 -04:00
|
|
|
use std::string::String as StdString;
|
2017-05-21 19:50:59 -04:00
|
|
|
|
2018-09-24 22:14:50 -04:00
|
|
|
use num_traits::cast;
|
|
|
|
|
A lot of performance changes.
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-11 23:20:10 -04:00
|
|
|
use error::{Error, Result};
|
2018-08-05 09:51:39 -04:00
|
|
|
use function::Function;
|
|
|
|
use lua::Lua;
|
2017-09-15 16:03:14 -04:00
|
|
|
use string::String;
|
|
|
|
use table::Table;
|
2017-12-04 00:57:39 -05:00
|
|
|
use thread::Thread;
|
2018-09-24 22:14:50 -04:00
|
|
|
use types::{LightUserData, Number};
|
2018-08-05 09:51:39 -04:00
|
|
|
use userdata::{AnyUserData, UserData};
|
2017-12-04 01:04:12 -05:00
|
|
|
use value::{FromLua, Nil, ToLua, Value};
|
2017-05-21 19:50:59 -04:00
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> ToLua<'lua> for Value<'lua> {
|
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
2017-05-21 19:50:59 -04:00
|
|
|
Ok(self)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> FromLua<'lua> for Value<'lua> {
|
|
|
|
fn from_lua(lua_value: Value<'lua>, _: &'lua Lua) -> Result<Self> {
|
2017-05-21 19:50:59 -04:00
|
|
|
Ok(lua_value)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-20 05:33:15 -04:00
|
|
|
impl<'lua> ToLua<'lua> for String<'lua> {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::String(self))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-20 05:33:15 -04:00
|
|
|
impl<'lua> FromLua<'lua> for String<'lua> {
|
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<String<'lua>> {
|
Improve the situation with numerical conversion
This is a somewhat involved change with two breaking API changes:
1) Lua::coerce_xxx methods now return Option (this is easier and faster than
dealing with Result)
2) rlua numeric conversions now allow more loss of precision
conversions (e.g. 1.5f32 to 1i32)
The logic for the first breaking change is that mostly the coerce methods are
probably used internally, and they make sense as low-level fallible casts and
are now used as such, and there's no reason to confuse things with a Result with
a large error type and force the user to match on the error which will hopefully
only be FromLuaConversionError anyway.
The logic for the second change is that it matches the behavior of
num_traits::cast, and is more consistent in that *some* loss of precision
conversions were previously allowed (e.g. f64 to f32).
The problem is that now, Lua::coerce_integer and Lua::unpack::<i64> have
different behavior when given, for example, the number 1.5. I still think this
is the best option, though, because the Lua::coerce_xxx methods represent how
Lua works internally and the standard C API cast functions that Lua provides,
and the ToLua / FromLua code represents the most common form of fallible Rust
numeric conversion.
I could revert this change and turn `Lua::eval::<i64>("1.5", None)` back into an
error, but it seems inconsistent to allow f64 -> f32 loss of precision but not
f64 -> i64 loss of precision.
2018-09-26 20:41:07 -04:00
|
|
|
let ty = value.type_name();
|
2017-05-21 19:50:59 -04:00
|
|
|
lua.coerce_string(value)
|
Improve the situation with numerical conversion
This is a somewhat involved change with two breaking API changes:
1) Lua::coerce_xxx methods now return Option (this is easier and faster than
dealing with Result)
2) rlua numeric conversions now allow more loss of precision
conversions (e.g. 1.5f32 to 1i32)
The logic for the first breaking change is that mostly the coerce methods are
probably used internally, and they make sense as low-level fallible casts and
are now used as such, and there's no reason to confuse things with a Result with
a large error type and force the user to match on the error which will hopefully
only be FromLuaConversionError anyway.
The logic for the second change is that it matches the behavior of
num_traits::cast, and is more consistent in that *some* loss of precision
conversions were previously allowed (e.g. f64 to f32).
The problem is that now, Lua::coerce_integer and Lua::unpack::<i64> have
different behavior when given, for example, the number 1.5. I still think this
is the best option, though, because the Lua::coerce_xxx methods represent how
Lua works internally and the standard C API cast functions that Lua provides,
and the ToLua / FromLua code represents the most common form of fallible Rust
numeric conversion.
I could revert this change and turn `Lua::eval::<i64>("1.5", None)` back into an
error, but it seems inconsistent to allow f64 -> f32 loss of precision but not
f64 -> i64 loss of precision.
2018-09-26 20:41:07 -04:00
|
|
|
.ok_or_else(|| Error::FromLuaConversionError {
|
|
|
|
from: ty,
|
|
|
|
to: "String",
|
|
|
|
message: Some("expected string or number".to_string()),
|
|
|
|
})
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> ToLua<'lua> for Table<'lua> {
|
2018-03-19 14:35:46 -04:00
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
2017-07-18 16:21:12 -04:00
|
|
|
Ok(Value::Table(self))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> FromLua<'lua> for Table<'lua> {
|
|
|
|
fn from_lua(value: Value<'lua>, _: &'lua Lua) -> Result<Table<'lua>> {
|
2017-05-21 19:50:59 -04:00
|
|
|
match value {
|
2017-07-18 16:21:12 -04:00
|
|
|
Value::Table(table) => Ok(table),
|
2017-08-01 13:36:26 -04:00
|
|
|
_ => Err(Error::FromLuaConversionError {
|
|
|
|
from: value.type_name(),
|
|
|
|
to: "table",
|
|
|
|
message: None,
|
|
|
|
}),
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> ToLua<'lua> for Function<'lua> {
|
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Function(self))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> FromLua<'lua> for Function<'lua> {
|
|
|
|
fn from_lua(value: Value<'lua>, _: &'lua Lua) -> Result<Function<'lua>> {
|
2017-05-21 19:50:59 -04:00
|
|
|
match value {
|
2017-07-18 16:21:12 -04:00
|
|
|
Value::Function(table) => Ok(table),
|
2017-08-01 13:36:26 -04:00
|
|
|
_ => Err(Error::FromLuaConversionError {
|
|
|
|
from: value.type_name(),
|
|
|
|
to: "function",
|
|
|
|
message: None,
|
|
|
|
}),
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> ToLua<'lua> for Thread<'lua> {
|
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Thread(self))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> FromLua<'lua> for Thread<'lua> {
|
|
|
|
fn from_lua(value: Value<'lua>, _: &'lua Lua) -> Result<Thread<'lua>> {
|
2017-05-21 19:50:59 -04:00
|
|
|
match value {
|
2017-07-18 16:21:12 -04:00
|
|
|
Value::Thread(t) => Ok(t),
|
2017-08-01 13:36:26 -04:00
|
|
|
_ => Err(Error::FromLuaConversionError {
|
|
|
|
from: value.type_name(),
|
|
|
|
to: "thread",
|
|
|
|
message: None,
|
|
|
|
}),
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> ToLua<'lua> for AnyUserData<'lua> {
|
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::UserData(self))
|
2017-05-24 23:13:58 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> FromLua<'lua> for AnyUserData<'lua> {
|
|
|
|
fn from_lua(value: Value<'lua>, _: &'lua Lua) -> Result<AnyUserData<'lua>> {
|
2017-05-24 23:13:58 -04:00
|
|
|
match value {
|
2017-07-18 16:21:12 -04:00
|
|
|
Value::UserData(ud) => Ok(ud),
|
2017-08-01 13:36:26 -04:00
|
|
|
_ => Err(Error::FromLuaConversionError {
|
|
|
|
from: value.type_name(),
|
|
|
|
to: "userdata",
|
|
|
|
message: None,
|
|
|
|
}),
|
2017-05-24 23:13:58 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-09-04 03:40:13 -04:00
|
|
|
impl<'lua, T: 'static + Send + UserData> ToLua<'lua> for T {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
2017-12-03 23:45:00 -05:00
|
|
|
Ok(Value::UserData(lua.create_userdata(self)?))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-09-04 03:40:13 -04:00
|
|
|
impl<'lua, T: 'static + UserData + Clone> FromLua<'lua> for T {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn from_lua(value: Value<'lua>, _: &'lua Lua) -> Result<T> {
|
2017-05-21 19:50:59 -04:00
|
|
|
match value {
|
2017-07-29 09:53:37 -04:00
|
|
|
Value::UserData(ud) => Ok(ud.borrow::<T>()?.clone()),
|
2017-08-01 13:36:26 -04:00
|
|
|
_ => Err(Error::FromLuaConversionError {
|
|
|
|
from: value.type_name(),
|
|
|
|
to: "userdata",
|
|
|
|
message: None,
|
|
|
|
}),
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> ToLua<'lua> for Error {
|
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Error(self))
|
2017-06-25 01:47:55 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> FromLua<'lua> for Error {
|
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<Error> {
|
2017-06-25 01:47:55 -04:00
|
|
|
match value {
|
2017-07-18 16:21:12 -04:00
|
|
|
Value::Error(err) => Ok(err),
|
|
|
|
val => Ok(Error::RuntimeError(
|
2017-06-25 02:04:14 -04:00
|
|
|
lua.coerce_string(val)
|
Improve the situation with numerical conversion
This is a somewhat involved change with two breaking API changes:
1) Lua::coerce_xxx methods now return Option (this is easier and faster than
dealing with Result)
2) rlua numeric conversions now allow more loss of precision
conversions (e.g. 1.5f32 to 1i32)
The logic for the first breaking change is that mostly the coerce methods are
probably used internally, and they make sense as low-level fallible casts and
are now used as such, and there's no reason to confuse things with a Result with
a large error type and force the user to match on the error which will hopefully
only be FromLuaConversionError anyway.
The logic for the second change is that it matches the behavior of
num_traits::cast, and is more consistent in that *some* loss of precision
conversions were previously allowed (e.g. f64 to f32).
The problem is that now, Lua::coerce_integer and Lua::unpack::<i64> have
different behavior when given, for example, the number 1.5. I still think this
is the best option, though, because the Lua::coerce_xxx methods represent how
Lua works internally and the standard C API cast functions that Lua provides,
and the ToLua / FromLua code represents the most common form of fallible Rust
numeric conversion.
I could revert this change and turn `Lua::eval::<i64>("1.5", None)` back into an
error, but it seems inconsistent to allow f64 -> f32 loss of precision but not
f64 -> i64 loss of precision.
2018-09-26 20:41:07 -04:00
|
|
|
.and_then(|s| Some(s.to_str().ok()?.to_owned()))
|
|
|
|
.unwrap_or_else(|| "<unprintable error>".to_owned()),
|
2017-06-25 02:04:14 -04:00
|
|
|
)),
|
2017-06-25 01:47:55 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-21 19:50:59 -04:00
|
|
|
impl<'lua> ToLua<'lua> for bool {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Boolean(self))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua> FromLua<'lua> for bool {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn from_lua(v: Value, _: &'lua Lua) -> Result<Self> {
|
2017-05-21 19:50:59 -04:00
|
|
|
match v {
|
2017-07-18 16:21:12 -04:00
|
|
|
Value::Nil => Ok(false),
|
|
|
|
Value::Boolean(b) => Ok(b),
|
2017-05-21 19:50:59 -04:00
|
|
|
_ => Ok(true),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> ToLua<'lua> for LightUserData {
|
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::LightUserData(self))
|
2017-05-25 00:43:35 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> FromLua<'lua> for LightUserData {
|
2017-08-01 13:36:26 -04:00
|
|
|
fn from_lua(value: Value, _: &'lua Lua) -> Result<Self> {
|
|
|
|
match value {
|
2017-07-18 16:21:12 -04:00
|
|
|
Value::LightUserData(ud) => Ok(ud),
|
2017-08-01 13:36:26 -04:00
|
|
|
_ => Err(Error::FromLuaConversionError {
|
|
|
|
from: value.type_name(),
|
|
|
|
to: "light userdata",
|
|
|
|
message: None,
|
|
|
|
}),
|
2017-05-25 00:43:35 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-20 05:33:15 -04:00
|
|
|
impl<'lua> ToLua<'lua> for StdString {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
2017-12-03 23:45:00 -05:00
|
|
|
Ok(Value::String(lua.create_string(&self)?))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-20 05:33:15 -04:00
|
|
|
impl<'lua> FromLua<'lua> for StdString {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<Self> {
|
Improve the situation with numerical conversion
This is a somewhat involved change with two breaking API changes:
1) Lua::coerce_xxx methods now return Option (this is easier and faster than
dealing with Result)
2) rlua numeric conversions now allow more loss of precision
conversions (e.g. 1.5f32 to 1i32)
The logic for the first breaking change is that mostly the coerce methods are
probably used internally, and they make sense as low-level fallible casts and
are now used as such, and there's no reason to confuse things with a Result with
a large error type and force the user to match on the error which will hopefully
only be FromLuaConversionError anyway.
The logic for the second change is that it matches the behavior of
num_traits::cast, and is more consistent in that *some* loss of precision
conversions were previously allowed (e.g. f64 to f32).
The problem is that now, Lua::coerce_integer and Lua::unpack::<i64> have
different behavior when given, for example, the number 1.5. I still think this
is the best option, though, because the Lua::coerce_xxx methods represent how
Lua works internally and the standard C API cast functions that Lua provides,
and the ToLua / FromLua code represents the most common form of fallible Rust
numeric conversion.
I could revert this change and turn `Lua::eval::<i64>("1.5", None)` back into an
error, but it seems inconsistent to allow f64 -> f32 loss of precision but not
f64 -> i64 loss of precision.
2018-09-26 20:41:07 -04:00
|
|
|
let ty = value.type_name();
|
|
|
|
Ok(lua
|
|
|
|
.coerce_string(value)
|
|
|
|
.ok_or_else(|| Error::FromLuaConversionError {
|
|
|
|
from: ty,
|
|
|
|
to: "String",
|
|
|
|
message: Some("expected string or number".to_string()),
|
|
|
|
})?.to_str()?
|
|
|
|
.to_owned())
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, 'a> ToLua<'lua> for &'a str {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
2017-12-03 23:45:00 -05:00
|
|
|
Ok(Value::String(lua.create_string(self)?))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
macro_rules! lua_convert_int {
|
2018-08-05 09:51:39 -04:00
|
|
|
($x:ty) => {
|
2017-05-21 19:50:59 -04:00
|
|
|
impl<'lua> ToLua<'lua> for $x {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
Improve the situation with numerical conversion
This is a somewhat involved change with two breaking API changes:
1) Lua::coerce_xxx methods now return Option (this is easier and faster than
dealing with Result)
2) rlua numeric conversions now allow more loss of precision
conversions (e.g. 1.5f32 to 1i32)
The logic for the first breaking change is that mostly the coerce methods are
probably used internally, and they make sense as low-level fallible casts and
are now used as such, and there's no reason to confuse things with a Result with
a large error type and force the user to match on the error which will hopefully
only be FromLuaConversionError anyway.
The logic for the second change is that it matches the behavior of
num_traits::cast, and is more consistent in that *some* loss of precision
conversions were previously allowed (e.g. f64 to f32).
The problem is that now, Lua::coerce_integer and Lua::unpack::<i64> have
different behavior when given, for example, the number 1.5. I still think this
is the best option, though, because the Lua::coerce_xxx methods represent how
Lua works internally and the standard C API cast functions that Lua provides,
and the ToLua / FromLua code represents the most common form of fallible Rust
numeric conversion.
I could revert this change and turn `Lua::eval::<i64>("1.5", None)` back into an
error, but it seems inconsistent to allow f64 -> f32 loss of precision but not
f64 -> i64 loss of precision.
2018-09-26 20:41:07 -04:00
|
|
|
if let Some(i) = cast(self) {
|
|
|
|
Ok(Value::Integer(i))
|
|
|
|
} else {
|
|
|
|
cast(self)
|
|
|
|
.ok_or_else(|| Error::ToLuaConversionError {
|
|
|
|
from: stringify!($x),
|
|
|
|
to: "number",
|
|
|
|
message: Some("out of range".to_owned()),
|
|
|
|
}).map(Value::Number)
|
|
|
|
}
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua> FromLua<'lua> for $x {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<Self> {
|
Improve the situation with numerical conversion
This is a somewhat involved change with two breaking API changes:
1) Lua::coerce_xxx methods now return Option (this is easier and faster than
dealing with Result)
2) rlua numeric conversions now allow more loss of precision
conversions (e.g. 1.5f32 to 1i32)
The logic for the first breaking change is that mostly the coerce methods are
probably used internally, and they make sense as low-level fallible casts and
are now used as such, and there's no reason to confuse things with a Result with
a large error type and force the user to match on the error which will hopefully
only be FromLuaConversionError anyway.
The logic for the second change is that it matches the behavior of
num_traits::cast, and is more consistent in that *some* loss of precision
conversions were previously allowed (e.g. f64 to f32).
The problem is that now, Lua::coerce_integer and Lua::unpack::<i64> have
different behavior when given, for example, the number 1.5. I still think this
is the best option, though, because the Lua::coerce_xxx methods represent how
Lua works internally and the standard C API cast functions that Lua provides,
and the ToLua / FromLua code represents the most common form of fallible Rust
numeric conversion.
I could revert this change and turn `Lua::eval::<i64>("1.5", None)` back into an
error, but it seems inconsistent to allow f64 -> f32 loss of precision but not
f64 -> i64 loss of precision.
2018-09-26 20:41:07 -04:00
|
|
|
let ty = value.type_name();
|
|
|
|
(if let Some(i) = lua.coerce_integer(value.clone()) {
|
|
|
|
cast(i)
|
|
|
|
} else {
|
|
|
|
cast(
|
|
|
|
lua.coerce_number(value)
|
|
|
|
.ok_or_else(|| Error::FromLuaConversionError {
|
|
|
|
from: ty,
|
|
|
|
to: stringify!($x),
|
|
|
|
message: Some(
|
|
|
|
"expected number or string coercible to number".to_string(),
|
|
|
|
),
|
|
|
|
})?,
|
|
|
|
)
|
|
|
|
}).ok_or_else(|| Error::FromLuaConversionError {
|
|
|
|
from: ty,
|
2018-09-24 22:14:50 -04:00
|
|
|
to: stringify!($x),
|
Improve the situation with numerical conversion
This is a somewhat involved change with two breaking API changes:
1) Lua::coerce_xxx methods now return Option (this is easier and faster than
dealing with Result)
2) rlua numeric conversions now allow more loss of precision
conversions (e.g. 1.5f32 to 1i32)
The logic for the first breaking change is that mostly the coerce methods are
probably used internally, and they make sense as low-level fallible casts and
are now used as such, and there's no reason to confuse things with a Result with
a large error type and force the user to match on the error which will hopefully
only be FromLuaConversionError anyway.
The logic for the second change is that it matches the behavior of
num_traits::cast, and is more consistent in that *some* loss of precision
conversions were previously allowed (e.g. f64 to f32).
The problem is that now, Lua::coerce_integer and Lua::unpack::<i64> have
different behavior when given, for example, the number 1.5. I still think this
is the best option, though, because the Lua::coerce_xxx methods represent how
Lua works internally and the standard C API cast functions that Lua provides,
and the ToLua / FromLua code represents the most common form of fallible Rust
numeric conversion.
I could revert this change and turn `Lua::eval::<i64>("1.5", None)` back into an
error, but it seems inconsistent to allow f64 -> f32 loss of precision but not
f64 -> i64 loss of precision.
2018-09-26 20:41:07 -04:00
|
|
|
message: Some("out of range".to_owned()),
|
2018-09-24 22:14:50 -04:00
|
|
|
})
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
2018-08-05 09:51:39 -04:00
|
|
|
};
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
lua_convert_int!(i8);
|
|
|
|
lua_convert_int!(u8);
|
|
|
|
lua_convert_int!(i16);
|
|
|
|
lua_convert_int!(u16);
|
|
|
|
lua_convert_int!(i32);
|
|
|
|
lua_convert_int!(u32);
|
|
|
|
lua_convert_int!(i64);
|
|
|
|
lua_convert_int!(u64);
|
2018-09-24 22:14:50 -04:00
|
|
|
lua_convert_int!(i128);
|
|
|
|
lua_convert_int!(u128);
|
2017-05-21 19:50:59 -04:00
|
|
|
lua_convert_int!(isize);
|
|
|
|
lua_convert_int!(usize);
|
|
|
|
|
|
|
|
macro_rules! lua_convert_float {
|
2018-08-05 09:51:39 -04:00
|
|
|
($x:ty) => {
|
2017-05-21 19:50:59 -04:00
|
|
|
impl<'lua> ToLua<'lua> for $x {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Number(self as Number))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua> FromLua<'lua> for $x {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<Self> {
|
Improve the situation with numerical conversion
This is a somewhat involved change with two breaking API changes:
1) Lua::coerce_xxx methods now return Option (this is easier and faster than
dealing with Result)
2) rlua numeric conversions now allow more loss of precision
conversions (e.g. 1.5f32 to 1i32)
The logic for the first breaking change is that mostly the coerce methods are
probably used internally, and they make sense as low-level fallible casts and
are now used as such, and there's no reason to confuse things with a Result with
a large error type and force the user to match on the error which will hopefully
only be FromLuaConversionError anyway.
The logic for the second change is that it matches the behavior of
num_traits::cast, and is more consistent in that *some* loss of precision
conversions were previously allowed (e.g. f64 to f32).
The problem is that now, Lua::coerce_integer and Lua::unpack::<i64> have
different behavior when given, for example, the number 1.5. I still think this
is the best option, though, because the Lua::coerce_xxx methods represent how
Lua works internally and the standard C API cast functions that Lua provides,
and the ToLua / FromLua code represents the most common form of fallible Rust
numeric conversion.
I could revert this change and turn `Lua::eval::<i64>("1.5", None)` back into an
error, but it seems inconsistent to allow f64 -> f32 loss of precision but not
f64 -> i64 loss of precision.
2018-09-26 20:41:07 -04:00
|
|
|
let ty = value.type_name();
|
|
|
|
lua.coerce_number(value)
|
|
|
|
.ok_or_else(|| Error::FromLuaConversionError {
|
|
|
|
from: ty,
|
|
|
|
to: stringify!($x),
|
|
|
|
message: Some("expected number or string coercible to number".to_string()),
|
|
|
|
}).and_then(|n| {
|
|
|
|
cast(n).ok_or_else(|| Error::FromLuaConversionError {
|
|
|
|
from: ty,
|
|
|
|
to: stringify!($x),
|
|
|
|
message: Some("number out of range".to_string()),
|
|
|
|
})
|
|
|
|
})
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
2018-08-05 09:51:39 -04:00
|
|
|
};
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
lua_convert_float!(f32);
|
|
|
|
lua_convert_float!(f64);
|
|
|
|
|
|
|
|
impl<'lua, T: ToLua<'lua>> ToLua<'lua> for Vec<T> {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Table(lua.create_sequence_from(self)?))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, T: FromLua<'lua>> FromLua<'lua> for Vec<T> {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn from_lua(value: Value<'lua>, _: &'lua Lua) -> Result<Self> {
|
|
|
|
if let Value::Table(table) = value {
|
2017-06-20 19:04:25 -04:00
|
|
|
table.sequence_values().collect()
|
2017-05-21 19:50:59 -04:00
|
|
|
} else {
|
2017-08-01 13:36:26 -04:00
|
|
|
Err(Error::FromLuaConversionError {
|
|
|
|
from: value.type_name(),
|
|
|
|
to: "Vec",
|
2017-08-02 07:56:28 -04:00
|
|
|
message: Some("expected table".to_string()),
|
2017-08-01 13:36:26 -04:00
|
|
|
})
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-24 16:15:57 -04:00
|
|
|
impl<'lua, K: Eq + Hash + ToLua<'lua>, V: ToLua<'lua>, S: BuildHasher> ToLua<'lua>
|
2018-03-19 14:35:46 -04:00
|
|
|
for HashMap<K, V, S>
|
|
|
|
{
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Table(lua.create_table_from(self)?))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-24 16:15:57 -04:00
|
|
|
impl<'lua, K: Eq + Hash + FromLua<'lua>, V: FromLua<'lua>, S: BuildHasher + Default> FromLua<'lua>
|
2018-03-19 14:35:46 -04:00
|
|
|
for HashMap<K, V, S>
|
|
|
|
{
|
2017-07-18 16:21:12 -04:00
|
|
|
fn from_lua(value: Value<'lua>, _: &'lua Lua) -> Result<Self> {
|
|
|
|
if let Value::Table(table) = value {
|
2017-06-19 02:57:03 -04:00
|
|
|
table.pairs().collect()
|
2017-05-21 19:50:59 -04:00
|
|
|
} else {
|
2017-08-01 13:36:26 -04:00
|
|
|
Err(Error::FromLuaConversionError {
|
|
|
|
from: value.type_name(),
|
|
|
|
to: "HashMap",
|
2017-08-02 07:56:28 -04:00
|
|
|
message: Some("expected table".to_string()),
|
2017-08-01 13:36:26 -04:00
|
|
|
})
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, K: Ord + ToLua<'lua>, V: ToLua<'lua>> ToLua<'lua> for BTreeMap<K, V> {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Table(lua.create_table_from(self)?))
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, K: Ord + FromLua<'lua>, V: FromLua<'lua>> FromLua<'lua> for BTreeMap<K, V> {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn from_lua(value: Value<'lua>, _: &'lua Lua) -> Result<Self> {
|
|
|
|
if let Value::Table(table) = value {
|
2017-06-19 02:57:03 -04:00
|
|
|
table.pairs().collect()
|
2017-05-21 19:50:59 -04:00
|
|
|
} else {
|
2017-08-01 13:36:26 -04:00
|
|
|
Err(Error::FromLuaConversionError {
|
|
|
|
from: value.type_name(),
|
|
|
|
to: "BTreeMap",
|
2017-08-02 07:56:28 -04:00
|
|
|
message: Some("expected table".to_string()),
|
2017-08-01 13:36:26 -04:00
|
|
|
})
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, T: ToLua<'lua>> ToLua<'lua> for Option<T> {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
2017-05-21 19:50:59 -04:00
|
|
|
match self {
|
|
|
|
Some(val) => val.to_lua(lua),
|
2017-07-24 07:12:52 -04:00
|
|
|
None => Ok(Nil),
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, T: FromLua<'lua>> FromLua<'lua> for Option<T> {
|
2017-07-18 16:21:12 -04:00
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<Self> {
|
2017-05-21 19:50:59 -04:00
|
|
|
match value {
|
2017-07-24 07:12:52 -04:00
|
|
|
Nil => Ok(None),
|
2017-05-21 19:50:59 -04:00
|
|
|
value => Ok(Some(T::from_lua(value, lua)?)),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|