2017-10-23 16:42:20 -04:00
|
|
|
use std::collections::{BTreeMap, HashMap};
|
2019-09-27 12:27:37 -04:00
|
|
|
use std::ffi::{CStr, CString};
|
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
|
|
|
|
2019-09-27 12:27:37 -04:00
|
|
|
use bstr::{BStr, BString};
|
2018-09-24 22:14:50 -04:00
|
|
|
use num_traits::cast;
|
|
|
|
|
2019-09-27 12:27:37 -04:00
|
|
|
use crate::error::{Error, Result};
|
|
|
|
use crate::function::Function;
|
|
|
|
use crate::lua::Lua;
|
|
|
|
use crate::string::String;
|
|
|
|
use crate::table::Table;
|
|
|
|
use crate::thread::Thread;
|
2020-05-06 08:18:04 -04:00
|
|
|
use crate::types::{LightUserData, Number, MaybeSend};
|
2019-09-27 12:27:37 -04:00
|
|
|
use crate::userdata::{AnyUserData, UserData};
|
|
|
|
use crate::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();
|
2019-09-27 12:27:37 -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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-06 08:18:04 -04:00
|
|
|
impl<'lua, T: 'static + MaybeSend + 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(
|
2019-09-27 12:27:37 -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 {
|
2020-04-17 17:38:01 -04:00
|
|
|
fn from_lua(v: Value<'lua>, _: &'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 {
|
2020-04-17 17:38:01 -04:00
|
|
|
fn from_lua(value: Value<'lua>, _: &'lua Lua) -> Result<Self> {
|
2017-08-01 13:36:26 -04:00
|
|
|
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
|
2019-09-27 12:27:37 -04:00
|
|
|
.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()),
|
2019-09-27 12:27:37 -04:00
|
|
|
})?
|
|
|
|
.to_str()?
|
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
|
|
|
.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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-27 12:27:37 -04:00
|
|
|
impl<'lua> ToLua<'lua> for CString {
|
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::String(lua.create_string(self.as_bytes())?))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua> FromLua<'lua> for CString {
|
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<Self> {
|
|
|
|
let ty = value.type_name();
|
|
|
|
let string = lua
|
|
|
|
.coerce_string(value)?
|
|
|
|
.ok_or_else(|| Error::FromLuaConversionError {
|
|
|
|
from: ty,
|
|
|
|
to: "CString",
|
|
|
|
message: Some("expected string or number".to_string()),
|
|
|
|
})?;
|
|
|
|
|
|
|
|
match CStr::from_bytes_with_nul(string.as_bytes_with_nul()) {
|
|
|
|
Ok(s) => Ok(s.into()),
|
|
|
|
Err(_) => Err(Error::FromLuaConversionError {
|
|
|
|
from: ty,
|
|
|
|
to: "CString",
|
|
|
|
message: Some("invalid C-style string".to_string()),
|
|
|
|
}),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, 'a> ToLua<'lua> for &'a CStr {
|
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::String(lua.create_string(self.to_bytes())?))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, 'a> ToLua<'lua> for BString {
|
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::String(lua.create_string(&self)?))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua> FromLua<'lua> for BString {
|
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<Self> {
|
|
|
|
let ty = value.type_name();
|
|
|
|
Ok(BString::from(
|
|
|
|
lua.coerce_string(value)?
|
|
|
|
.ok_or_else(|| Error::FromLuaConversionError {
|
|
|
|
from: ty,
|
|
|
|
to: "String",
|
|
|
|
message: Some("expected string or number".to_string()),
|
|
|
|
})?
|
|
|
|
.as_bytes()
|
|
|
|
.to_vec(),
|
|
|
|
))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, 'a> ToLua<'lua> for &BStr {
|
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
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()),
|
2019-09-27 12:27:37 -04:00
|
|
|
})
|
|
|
|
.map(Value::Number)
|
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
|
|
|
}
|
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();
|
2019-09-27 12:27:37 -04:00
|
|
|
(if let Some(i) = lua.coerce_integer(value.clone())? {
|
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
|
|
|
cast(i)
|
|
|
|
} else {
|
2019-09-27 12:27:37 -04:00
|
|
|
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 {
|
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
|
|
|
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();
|
2019-09-27 12:27:37 -04:00
|
|
|
lua.coerce_number(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: stringify!($x),
|
|
|
|
message: Some("expected number or string coercible to number".to_string()),
|
2019-09-27 12:27:37 -04:00
|
|
|
})
|
|
|
|
.and_then(|n| {
|
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
|
|
|
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);
|
|
|
|
|
2020-04-29 11:12:58 -04:00
|
|
|
impl<'lua, T> ToLua<'lua> for &'_ [T]
|
|
|
|
where
|
|
|
|
T: Clone + ToLua<'lua>,
|
|
|
|
{
|
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Table(
|
|
|
|
lua.create_sequence_from(self.into_iter().cloned())?,
|
|
|
|
))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
macro_rules! lua_convert_array {
|
|
|
|
($($N:literal)+) => {
|
|
|
|
$(
|
|
|
|
impl<'lua, T> ToLua<'lua> for [T; $N]
|
|
|
|
where
|
|
|
|
T: Clone + ToLua<'lua>,
|
|
|
|
{
|
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
(&self).to_lua(lua)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, T> ToLua<'lua> for &'_ [T; $N]
|
|
|
|
where
|
|
|
|
T: Clone + ToLua<'lua>,
|
|
|
|
{
|
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Table(
|
|
|
|
lua.create_sequence_from(self.iter().cloned())?,
|
|
|
|
))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
)+
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
lua_convert_array! {
|
|
|
|
0 1 2 3 4 5 6 7 8 9
|
|
|
|
10 11 12 13 14 15 16 17 18 19
|
|
|
|
20 21 22 23 24 25 26 27 28 29
|
|
|
|
30 31 32
|
|
|
|
}
|
|
|
|
|
2017-05-21 19:50:59 -04:00
|
|
|
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)?)),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|