Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
support luajit version 2.0.4
|
|
|
|
|
|
|
|
Initial Luau support work
|
|
|
|
|
|
See #114
|
|
|
|
|
|
lua51(jit)
|
|
|
|
I think this experiment is unsuccessful and does not work well in a module mode
with dynamic symbols resolution and mixing between different mlua instances.
Overall the Rust bug has been fixed and we can wait for the "C-unwind" feature become stable.
|
|
|
|
|
|
Motivation behind this change is upcoming breaking change in Rust
compiler v1.52.0 to prevent unwinding across FFI boundaries.
https://github.com/rust-lang/rust/pull/76570
The new functionality requires nightly compiler to declare FFI
functions as "C-unwind".
The fundamental solution is to use C shim to wrap "e" and "m"
Lua functions in pcall.
Additionally define Rust calling convention to trigger lua_error
on Rust behalf.
|
|
|
|
|
|
|
|
|
|
|
|
This commit teaches the build script to recognize when it is
cross-compiling and switch to an alternative approach for generating
the `glue.rs` module.
It defaults to the equivalent logic found in the lua headers to
set the default types and parameters.
Notably: it doesn't statically produce the default lua paths as we
cannot know these without either executing the code (not guaranteed
possible when cross compiling) or regexing out the paths from the
headers (a bit brittle). An alternative approach might be to use
something like `lazy_static` to ask the library for its compiled in
values once at runtime.
I've tested this with:
```
cargo build --target armv7-unknown-linux-gnueabihf --features lua51,vendored
cargo build --target armv7-unknown-linux-gnueabihf --features lua52,vendored
cargo build --target armv7-unknown-linux-gnueabihf --features lua53,vendored
cargo build --target armv7-unknown-linux-gnueabihf --features lua54,vendored
cargo build --target armv7-unknown-linux-gnueabihf --features luajit,vendored
```
All except luajit compile. Luajit itself doesn't cross compile, so I
don't think we can ever reasonably get that to work.
I haven't tried to run any of this yet; my use case is actually for mac
(https://github.com/wez/wezterm/pull/426) so I need to commit this and
try patching it in over there before I can see if that truly worked
end-to-end.
refs: https://github.com/khvzak/mlua/issues/14
|
|
|
|
Don't link module with Lua core (see: http://lua-users.org/wiki/BuildingModules)
Example and tests for modules
|
|
|
|
|
|
|
|
Cargo fmt and minor changes
|
|
Squashed commit of the async branch.
|
|
|
|
|