2021-05-04 18:42:33 -04:00
|
|
|
#![allow(clippy::wrong_self_convention)]
|
|
|
|
|
2021-02-26 05:23:36 -05:00
|
|
|
use std::borrow::Cow;
|
2020-09-27 20:54:47 -04:00
|
|
|
use std::collections::{BTreeMap, BTreeSet, HashMap, HashSet};
|
2021-11-03 20:59:19 -04:00
|
|
|
use std::convert::TryInto;
|
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};
|
2022-12-19 17:11:52 -05:00
|
|
|
use crate::function::Function;
|
2019-09-27 12:27:37 -04:00
|
|
|
use crate::lua::Lua;
|
2022-12-19 17:11:52 -05:00
|
|
|
use crate::string::String;
|
|
|
|
use crate::table::Table;
|
|
|
|
use crate::thread::Thread;
|
2021-01-20 05:44:32 -05:00
|
|
|
use crate::types::{LightUserData, MaybeSend};
|
2022-12-19 17:11:52 -05:00
|
|
|
use crate::userdata::{AnyUserData, UserData};
|
2019-09-27 12:27:37 -04:00
|
|
|
use crate::value::{FromLua, Nil, ToLua, Value};
|
2017-05-21 19:50:59 -04:00
|
|
|
|
2022-12-19 17:11:52 -05:00
|
|
|
#[cfg(feature = "unstable")]
|
|
|
|
use crate::{function::OwnedFunction, table::OwnedTable, userdata::OwnedAnyUserData};
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> ToLua<'lua> for Value<'lua> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-20 05:33:15 -04:00
|
|
|
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> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-12-19 17:11:52 -05:00
|
|
|
#[cfg(feature = "unstable")]
|
2022-10-16 18:36:26 -04:00
|
|
|
impl<'lua> ToLua<'lua> for OwnedTable {
|
|
|
|
#[inline]
|
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Table(Table(lua.adopt_owned_ref(self.0))))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-12-19 17:11:52 -05:00
|
|
|
#[cfg(feature = "unstable")]
|
2022-10-16 18:36:26 -04:00
|
|
|
impl<'lua> FromLua<'lua> for OwnedTable {
|
|
|
|
#[inline]
|
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<OwnedTable> {
|
|
|
|
Table::from_lua(value, lua).map(|s| s.into_owned())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> ToLua<'lua> for Function<'lua> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-12-19 17:11:52 -05:00
|
|
|
#[cfg(feature = "unstable")]
|
2022-10-16 18:36:26 -04:00
|
|
|
impl<'lua> ToLua<'lua> for OwnedFunction {
|
|
|
|
#[inline]
|
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Function(Function(lua.adopt_owned_ref(self.0))))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-12-19 17:11:52 -05:00
|
|
|
#[cfg(feature = "unstable")]
|
2022-10-16 18:36:26 -04:00
|
|
|
impl<'lua> FromLua<'lua> for OwnedFunction {
|
|
|
|
#[inline]
|
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<OwnedFunction> {
|
|
|
|
Function::from_lua(value, lua).map(|s| s.into_owned())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 16:21:12 -04:00
|
|
|
impl<'lua> ToLua<'lua> for Thread<'lua> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-12-19 17:11:52 -05:00
|
|
|
#[cfg(feature = "unstable")]
|
2022-10-16 18:36:26 -04:00
|
|
|
impl<'lua> ToLua<'lua> for OwnedAnyUserData {
|
|
|
|
#[inline]
|
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::UserData(AnyUserData(lua.adopt_owned_ref(self.0))))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-12-19 17:11:52 -05:00
|
|
|
#[cfg(feature = "unstable")]
|
2022-10-16 18:36:26 -04:00
|
|
|
impl<'lua> FromLua<'lua> for OwnedAnyUserData {
|
|
|
|
#[inline]
|
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<OwnedAnyUserData> {
|
|
|
|
AnyUserData::from_lua(value, lua).map(|s| s.into_owned())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-06 08:18:04 -04:00
|
|
|
impl<'lua, T: 'static + MaybeSend + UserData> ToLua<'lua> for T {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-10-16 18:36:26 -04:00
|
|
|
// TODO: Remove
|
2018-09-04 03:40:13 -04:00
|
|
|
impl<'lua, T: 'static + UserData + Clone> FromLua<'lua> for T {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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 {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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 {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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 {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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 {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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 {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
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 {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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 {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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 {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-13 19:22:48 -04:00
|
|
|
impl<'lua> ToLua<'lua> for &str {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-02-26 05:23:36 -05:00
|
|
|
impl<'lua> ToLua<'lua> for Cow<'_, str> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2021-02-26 05:23:36 -05:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::String(lua.create_string(self.as_bytes())?))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-05-02 20:15:36 -04:00
|
|
|
impl<'lua> ToLua<'lua> for Box<str> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2021-05-02 20:15:36 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::String(lua.create_string(&*self)?))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua> FromLua<'lua> for Box<str> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2021-05-02 20:15:36 -04:00
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<Self> {
|
|
|
|
let ty = value.type_name();
|
|
|
|
Ok(lua
|
|
|
|
.coerce_string(value)?
|
|
|
|
.ok_or_else(|| Error::FromLuaConversionError {
|
|
|
|
from: ty,
|
|
|
|
to: "Box<str>",
|
|
|
|
message: Some("expected string or number".to_string()),
|
|
|
|
})?
|
|
|
|
.to_str()?
|
|
|
|
.to_owned()
|
|
|
|
.into_boxed_str())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-27 12:27:37 -04:00
|
|
|
impl<'lua> ToLua<'lua> for CString {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2019-09-27 12:27:37 -04:00
|
|
|
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 {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2019-09-27 12:27:37 -04:00
|
|
|
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()),
|
|
|
|
}),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-13 19:22:48 -04:00
|
|
|
impl<'lua> ToLua<'lua> for &CStr {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2019-09-27 12:27:37 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::String(lua.create_string(self.to_bytes())?))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-02-26 05:23:36 -05:00
|
|
|
impl<'lua> ToLua<'lua> for Cow<'_, CStr> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2021-02-26 05:23:36 -05:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::String(lua.create_string(self.to_bytes())?))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-13 19:22:48 -04:00
|
|
|
impl<'lua> ToLua<'lua> for BString {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2019-09-27 12:27:37 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::String(lua.create_string(&self)?))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua> FromLua<'lua> for BString {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2019-09-27 12:27:37 -04:00
|
|
|
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(),
|
|
|
|
))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-13 19:22:48 -04:00
|
|
|
impl<'lua> ToLua<'lua> for &BStr {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2019-09-27 12:27:37 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
2022-05-29 15:17:09 -04:00
|
|
|
Ok(Value::String(lua.create_string(self)?))
|
2019-09-27 12:27:37 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
2021-11-04 09:15:26 -04:00
|
|
|
cast(self)
|
|
|
|
.map(Value::Integer)
|
|
|
|
.or_else(|| cast(self).map(Value::Number))
|
|
|
|
// This is impossible error because conversion to Number never fails
|
|
|
|
.ok_or_else(|| Error::ToLuaConversionError {
|
|
|
|
from: stringify!($x),
|
|
|
|
to: "number",
|
|
|
|
message: Some("out of range".to_owned()),
|
|
|
|
})
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua> FromLua<'lua> for $x {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
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();
|
2022-05-30 14:26:12 -04:00
|
|
|
(match value {
|
|
|
|
Value::Integer(i) => cast(i),
|
|
|
|
Value::Number(n) => cast(n),
|
|
|
|
_ => {
|
|
|
|
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(),
|
|
|
|
),
|
|
|
|
}
|
|
|
|
})?)
|
2019-09-27 12:27:37 -04:00
|
|
|
}
|
2022-05-30 14:26:12 -04:00
|
|
|
}
|
2019-09-27 12:27:37 -04:00
|
|
|
})
|
|
|
|
.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 {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2017-07-18 16:21:12 -04:00
|
|
|
fn to_lua(self, _: &'lua Lua) -> Result<Value<'lua>> {
|
2021-01-20 05:44:32 -05:00
|
|
|
cast(self)
|
|
|
|
.ok_or_else(|| Error::ToLuaConversionError {
|
|
|
|
from: stringify!($x),
|
|
|
|
to: "number",
|
|
|
|
message: Some("out of range".to_string()),
|
|
|
|
})
|
|
|
|
.map(Value::Number)
|
2017-05-21 19:50:59 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua> FromLua<'lua> for $x {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
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-05-13 19:22:48 -04:00
|
|
|
impl<'lua, T> ToLua<'lua> for &[T]
|
2020-04-29 11:12:58 -04:00
|
|
|
where
|
|
|
|
T: Clone + ToLua<'lua>,
|
|
|
|
{
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2020-04-29 11:12:58 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Table(
|
2020-05-12 18:34:42 -04:00
|
|
|
lua.create_sequence_from(self.iter().cloned())?,
|
2020-04-29 11:12:58 -04:00
|
|
|
))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-11-03 20:59:19 -04:00
|
|
|
impl<'lua, T, const N: usize> ToLua<'lua> for [T; N]
|
|
|
|
where
|
|
|
|
T: ToLua<'lua>,
|
|
|
|
{
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2021-11-03 20:59:19 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Table(lua.create_sequence_from(self)?))
|
2020-04-29 11:12:58 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-11-03 20:59:19 -04:00
|
|
|
impl<'lua, T, const N: usize> FromLua<'lua> for [T; N]
|
|
|
|
where
|
|
|
|
T: FromLua<'lua>,
|
|
|
|
{
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2022-03-22 16:52:10 -04:00
|
|
|
fn from_lua(value: Value<'lua>, _lua: &'lua Lua) -> Result<Self> {
|
|
|
|
match value {
|
|
|
|
#[cfg(feature = "luau")]
|
|
|
|
Value::Vector(x, y, z) if N == 3 => Ok(mlua_expect!(
|
|
|
|
vec![
|
|
|
|
T::from_lua(Value::Number(x as _), _lua)?,
|
|
|
|
T::from_lua(Value::Number(y as _), _lua)?,
|
|
|
|
T::from_lua(Value::Number(z as _), _lua)?,
|
|
|
|
]
|
|
|
|
.try_into()
|
|
|
|
.map_err(|_| ()),
|
|
|
|
"cannot convert vector to array"
|
|
|
|
)),
|
|
|
|
Value::Table(table) => {
|
|
|
|
let vec = table.sequence_values().collect::<Result<Vec<_>>>()?;
|
|
|
|
vec.try_into()
|
|
|
|
.map_err(|vec: Vec<T>| Error::FromLuaConversionError {
|
|
|
|
from: "Table",
|
|
|
|
to: "Array",
|
|
|
|
message: Some(format!("expected table of length {}, got {}", N, vec.len())),
|
|
|
|
})
|
|
|
|
}
|
|
|
|
_ => Err(Error::FromLuaConversionError {
|
2021-11-03 20:59:19 -04:00
|
|
|
from: value.type_name(),
|
|
|
|
to: "Array",
|
|
|
|
message: Some("expected table".to_string()),
|
2022-03-22 16:52:10 -04:00
|
|
|
}),
|
2021-11-03 20:59:19 -04:00
|
|
|
}
|
|
|
|
}
|
2020-04-29 11:12:58 -04:00
|
|
|
}
|
|
|
|
|
2021-05-02 20:15:36 -04:00
|
|
|
impl<'lua, T: ToLua<'lua>> ToLua<'lua> for Box<[T]> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2021-05-02 20:15:36 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Table(lua.create_sequence_from(self.into_vec())?))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, T: FromLua<'lua>> FromLua<'lua> for Box<[T]> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2022-03-22 16:52:10 -04:00
|
|
|
fn from_lua(value: Value<'lua>, lua: &'lua Lua) -> Result<Self> {
|
|
|
|
Ok(Vec::<T>::from_lua(value, lua)?.into_boxed_slice())
|
2021-05-02 20:15:36 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-21 19:50:59 -04:00
|
|
|
impl<'lua, T: ToLua<'lua>> ToLua<'lua> for Vec<T> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
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> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2022-03-22 16:52:10 -04:00
|
|
|
fn from_lua(value: Value<'lua>, _lua: &'lua Lua) -> Result<Self> {
|
|
|
|
match value {
|
|
|
|
#[cfg(feature = "luau")]
|
|
|
|
Value::Vector(x, y, z) => Ok(vec![
|
|
|
|
T::from_lua(Value::Number(x as _), _lua)?,
|
|
|
|
T::from_lua(Value::Number(y as _), _lua)?,
|
|
|
|
T::from_lua(Value::Number(z as _), _lua)?,
|
|
|
|
]),
|
|
|
|
Value::Table(table) => table.sequence_values().collect(),
|
|
|
|
_ => Err(Error::FromLuaConversionError {
|
2017-08-01 13:36:26 -04:00
|
|
|
from: value.type_name(),
|
|
|
|
to: "Vec",
|
2017-08-02 07:56:28 -04:00
|
|
|
message: Some("expected table".to_string()),
|
2022-03-22 16:52:10 -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>
|
|
|
|
{
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
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>
|
|
|
|
{
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
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> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
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> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-09-27 20:54:47 -04:00
|
|
|
impl<'lua, T: Eq + Hash + ToLua<'lua>, S: BuildHasher> ToLua<'lua> for HashSet<T, S> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2020-09-27 20:54:47 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Table(lua.create_table_from(
|
|
|
|
self.into_iter().map(|val| (val, true)),
|
|
|
|
)?))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, T: Eq + Hash + FromLua<'lua>, S: BuildHasher + Default> FromLua<'lua> for HashSet<T, S> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2020-09-27 20:54:47 -04:00
|
|
|
fn from_lua(value: Value<'lua>, _: &'lua Lua) -> Result<Self> {
|
2021-06-24 20:49:09 -04:00
|
|
|
match value {
|
|
|
|
Value::Table(table) if table.len()? > 0 => table.sequence_values().collect(),
|
|
|
|
Value::Table(table) => table
|
2020-09-27 20:54:47 -04:00
|
|
|
.pairs::<T, Value<'lua>>()
|
|
|
|
.map(|res| res.map(|(k, _)| k))
|
2021-06-24 20:49:09 -04:00
|
|
|
.collect(),
|
|
|
|
_ => Err(Error::FromLuaConversionError {
|
2020-09-27 20:54:47 -04:00
|
|
|
from: value.type_name(),
|
|
|
|
to: "HashSet",
|
|
|
|
message: Some("expected table".to_string()),
|
2021-06-24 20:49:09 -04:00
|
|
|
}),
|
2020-09-27 20:54:47 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, T: Ord + ToLua<'lua>> ToLua<'lua> for BTreeSet<T> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2020-09-27 20:54:47 -04:00
|
|
|
fn to_lua(self, lua: &'lua Lua) -> Result<Value<'lua>> {
|
|
|
|
Ok(Value::Table(lua.create_table_from(
|
|
|
|
self.into_iter().map(|val| (val, true)),
|
|
|
|
)?))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'lua, T: Ord + FromLua<'lua>> FromLua<'lua> for BTreeSet<T> {
|
2022-05-29 15:17:09 -04:00
|
|
|
#[inline]
|
2020-09-27 20:54:47 -04:00
|
|
|
fn from_lua(value: Value<'lua>, _: &'lua Lua) -> Result<Self> {
|
2021-06-24 20:49:09 -04:00
|
|
|
match value {
|
|
|
|
Value::Table(table) if table.len()? > 0 => table.sequence_values().collect(),
|
|
|
|
Value::Table(table) => table
|
2020-09-27 20:54:47 -04:00
|
|
|
.pairs::<T, Value<'lua>>()
|
|
|
|
.map(|res| res.map(|(k, _)| k))
|
2021-06-24 20:49:09 -04:00
|
|
|
.collect(),
|
|
|
|
_ => Err(Error::FromLuaConversionError {
|
2020-09-27 20:54:47 -04:00
|
|
|
from: value.type_name(),
|
|
|
|
to: "BTreeSet",
|
|
|
|
message: Some("expected table".to_string()),
|
2021-06-24 20:49:09 -04:00
|
|
|
}),
|
2020-09-27 20:54:47 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-21 19:50:59 -04:00
|
|
|
impl<'lua, T: ToLua<'lua>> ToLua<'lua> for Option<T> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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> {
|
2021-09-20 07:38:08 -04:00
|
|
|
#[inline]
|
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)?)),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|