Commit Graph

464 Commits

Author SHA1 Message Date
Alex Orlenko 11e22d1cba Temporary drop "compile-fail" tests due to unstable compiletest_rs crate 2019-09-30 22:34:20 +01:00
Alex Orlenko 2ca4273ffb Add call method to table 2019-09-30 22:15:27 +01:00
Alex Orlenko 78480b5f31 Use main state to store extra data and auxiliary registries 2019-09-30 22:14:58 +01:00
Alex Orlenko 54f4627195 Update tests (excl. compile-fail) 2019-09-29 13:03:32 +01:00
Alex Orlenko 45159bfda7 Add Table::raw_remove method 2019-09-29 12:56:06 +01:00
Alex Orlenko 0c230a3037 Allow to catch rust panics via pcall 2019-09-29 12:56:06 +01:00
Alex Orlenko b23ee6a162 cargo fmt 2019-09-29 12:56:03 +01:00
Alex Orlenko affa85feb0 Backport changes from rlua 0.16 (master branch) 2019-09-29 12:53:13 +01:00
Alex Orlenko 53b352466e Replace ffi module with implementation from "jcmoyer/rust-lua53" crate 2019-09-29 12:42:07 +01:00
Alex Orlenko 14a68dd6d2 Add dyn to trait objects 2019-09-29 12:42:07 +01:00
Alex Orlenko 47a8ac2b05 Allow only init Lua from an exiting state 2019-09-26 19:17:51 +01:00
Alex Orlenko b1aa8f8a80 Remove builtin lua 2019-08-08 18:54:08 +01:00
kyren da3d4c4998 (cargo-release) version 0.15.3 2018-10-13 17:56:42 -04:00
kyren d6998ca8fe update changelog for 0.15.3 2018-10-13 17:54:42 -04:00
kyren 0c1e5c7c5d fix broken .travis.yml 2018-10-13 17:51:44 -04:00
kyren f02444e5a7 add rustfmt checks to travis (stable channel) 2018-10-13 17:48:16 -04:00
kyren 917b432aa5 Merge pull request #96 from sakridge/fix-num-traits-version
Update num-traits dependency to 0.2.6
2018-10-11 14:35:00 -04:00
Stephen Akridge da6e92d16d Update num-traits dependency to 0.2.6
This crate requires i128 support which is not
added to num-traits until the 0.2.5 release and i128
detection is added in 0.2.6.
2018-10-11 10:40:03 -07:00
kyren 1a259284ab (cargo-release) start next development iteration 0.15.3-alpha.0 2018-10-01 06:10:35 -04:00
kyren 8db6709fb8 (cargo-release) version 0.15.2 2018-10-01 06:10:18 -04:00
kyren 929036f2c8 Update changelog for one more 0.15 last minute addition 2018-10-01 06:09:54 -04:00
kyren 65d8ad2f86 Allow non-utf8 Lua source in load / exec / eval 2018-10-01 06:00:21 -04:00
kyren 8538874dd3 Whoops, misplaced assert 2018-10-01 05:31:28 -04:00
kyren 4625ac9d52 Some more minor guided tour updates 2018-10-01 05:24:11 -04:00
kyren c7684fef32 Update comments in guided tour for recent additions 2018-10-01 05:20:05 -04:00
kyren e49ecbd6be (cargo-release) start next development iteration 0.15.2-alpha.0 2018-10-01 05:15:25 -04:00
kyren 5610748347 (cargo-release) version 0.15.1 2018-10-01 05:15:09 -04:00
kyren 51339ecb1d Some documentation and changelog fixes 2018-10-01 05:14:43 -04:00
kyren f8665ba334 (cargo-release) version 0.15.0 2018-10-01 04:53:22 -04:00
kyren d8a43f79b0 Update changelog for 0.15, fix readme for earlier tuple size increase 2018-09-30 16:31:05 -04:00
kyren 167184ae76 Allow arbitrary [u8] Lua strings 2018-09-30 15:42:04 -04:00
kyren 8810c36979 Add test for i128 Lua round-trip 2018-09-26 21:13:25 -04:00
kyren 6d17a383df Avoid mem::uninitialized in generic context as it is unsound with e.g. bool 2018-09-26 21:07:11 -04:00
kyren 58ce05ff9a 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 21:01:54 -04:00
kyren c3d0110722 Return rlua::Error on out of range numeric conversions using num_traits::cast 2018-09-24 22:14:50 -04:00
kyren 6a5ec6b387 cargo fmt 2018-09-24 22:13:42 -04:00
kyren 70b67052c9 Upgrade rustyline to 2.0 to avoid confusion 2018-09-24 21:27:29 -04:00
kyren 14090821d3 Make the changes I proposed to PR #79
Allows people (maybe only I care about this?) to build rlua in weird
environments.
2018-09-16 21:18:24 -04:00
kyren c07abdc03e Merge pull request #79 from acrisci/system-lua-pkg-config
find system lua with pkg-config
2018-09-16 20:57:45 -04:00
kyren 654fff7065 Next version will be 0.15 2018-09-16 20:19:46 -04:00
kyren b8da08187d Move integration tests into top-level tests directory
other minor refactors
2018-09-16 20:15:51 -04:00
kyren 4a587ca1c5 Add compilefail test for Scope::create_nonstatic_userdata 2018-09-16 19:54:58 -04:00
kyren 7eb71fb1df Rename Scope::create_userdata to Scope::create_nonstatic_userdata
avoids clashing with the previous method name to avoid confusion
2018-09-16 19:54:12 -04:00
kyren 58b991b83b Merge pull request #86 from kyren/unstatic
Allow non-'static UserData created from Scope
2018-09-16 19:42:14 -04:00
kyren 6153ec4b95 basic tests for nonstatic userdata 2018-09-04 19:41:00 -04:00
kyren add547b356 comment terminology... fix? 2018-09-04 19:09:09 -04:00
kyren 703601e348 code re-org have slightly less pub(crate) items 2018-09-04 19:05:21 -04:00
kyren 30a94c4dec Comment updates that I really hope are correct
Tried to explain the rationale for safety around callbacks in Lua and Scope a
bit better, because every time I don't look at this for a while I forget my
reasoning.  I'm not always so great at using the right terminology, so to
whoever reads this, if I got this wrong please tell me.
2018-09-04 17:36:06 -04:00
kyren bd00af2bac Initial design for non-'static scoped userdata
Uses the same UserData trait, and should at least in theory support everything
that 'static UserData does, except that any functions added that rely on
AnyUserData are pretty much useless.

Probably pretty slow and I'm not sure how to make it dramatically faster, which
is a shame because generally when you need non'-static userdata you might be
creating it kind of a lot (if it was long-lived, it would probably be 'static).

Haven't added tests yet, will do that next.
2018-09-04 03:40:13 -04:00
kyren 37165a8201 Don't leak userdata if the metatable creation errors or panics 2018-09-04 03:38:22 -04:00