$ cargo --version && rustc --version cargo 0.0.1-pre-nightly (e689383 2015-03-16) (built 2015-03-16) rustc 1.0.0-nightly (ecf8c64e1 2015-03-21) (built 2015-03-21)

This allows the tests to compile, but I'm getting linker errors, so I couldn't verify that they pass or even run. Compiling anything against rust-lua gives the same sorts of linker errors, so it's probably the same thing.

The enum change is pretty straight-forward, but I wasn't sure about the functions in std::num::{FloatMath, SignedInt}.

This change fixes the build on my machine.

Fairly new to Rust, so perhaps I'm missing something obvious. Below is a transcript of my attempt to add your module to a new Rust project. Environment is a fairly stock Ubuntu 14.04 Vagrant VM with lua5.1-dev freshly installed and Rust nightly as of this morning. It appears to fail at finding the config module.

Please let me know what additional details I can provide, or if I missed a step. Thanks!

Script started on Tue 18 Nov 2014 08:03:02 PM UTC
vagrant@vagrant-ubuntu-trusty-64:/vagrant$ uname -a
Linux vagrant-ubuntu-trusty-64 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
vagrant@vagrant-ubuntu-trusty-64:/vagrant$ rustc -v
rustc 0.13.0-nightly (336349c93 2014-11-17 20:37:19 +0000)
vagrant@vagrant-ubuntu-trusty-64:/vagrant$ cargo build
   Compiling lua v0.1.0 (https://github.com/kballard/rust-lua#f26945f3)
/home/vagrant/.cargo/git/checkouts/rust-lua-03432044e2906b55/master/src/lib.rs:48:9: 48:15 error: file not found for module `config`
/home/vagrant/.cargo/git/checkouts/rust-lua-03432044e2906b55/master/src/lib.rs:48 pub mod config;
                                                                                          ^~~~~~
/home/vagrant/.cargo/git/checkouts/rust-lua-03432044e2906b55/master/src/lib.rs:48:9: 48:15 help: name the file either config.rs or config/mod.rs inside the directory /home/vagrant/.cargo/git/checkouts/rust-lua-03432044e2906b55/master/src
/home/vagrant/.cargo/git/checkouts/rust-lua-03432044e2906b55/master/src/lib.rs:48 pub mod config;
                                                                                          ^~~~~~
Build failed, waiting for other jobs to finish...
Could not compile `lua`.

To learn more, run the command again with --verbose.
vagrant@vagrant-ubuntu-trusty-64:/vagrant$ exit
Script done on Tue 18 Nov 2014 08:03:22 PM UTC

I removed a bunch of lifetimes (unnecessary?) and used std::thread::Builder instead of std::thread::Thread to get information about panics from the thread.

There's still a bunch of compile warnings, but this at least cleans up the errors.

Currently rust-lua is failing on nightly (maybe stable as well?)

These changes get it to work on my version of nightly:

$ rustc --version
rustc 1.9.0-nightly (600dc3552 2016-04-04)

Do the current unit tests cover the affected functions?

I fixed this on my machine:

diff --git a/Makefile b/Makefile
index b8d354c..9e61983 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@

 LUA_PCNAME = $(if $(shell pkg-config --exists lua5.1 && echo yes),lua5.1,lua)
 LUA_LIBNAME = $(firstword $(patsubst -llua%,lua%,$(filter -llua%,$(shell pkg-config --libs-only-l $(LUA_PCNAME)))))
-LUA_LIBDIRS = $(patsubst -L%,%,$(shell pkg-config --libs-only-L $(LUA_PCNAME)))
+LUA_LIBDIRS = $(patsubst %,%,$(shell pkg-config --libs-only-L $(LUA_PCNAME)))
 CFLAGS += $(shell pkg-config --cflags $(LUA_PCNAME))

 lib:
@@ -26,7 +26,7 @@ else
 # the rest of the Makefile is only visible to Cargo

 cargo-prep: $(OUT_DIR)/config.rs
-   @echo "cargo:rustc-flags=-l $(LUA_LIBNAME) -L native=$(LUA_LIBDIRS)"
+   @echo "cargo:rustc-flags=-l $(LUA_LIBNAME) $(LUA_LIBDIRS)"

 $(OUT_DIR)/config.rs: $(OUT_DIR)/gen-config
    echo "pub mod config {" > $@

I don't know enough about make or linker arguments to know if this is the proper solution. For me, pkg-config --libs-only-L lua5.1 returns nothing, which is why this change works. I assume there was a reason for stripping the -L from LUA_LIBDIRS though, so I thought I'd submit this as an issue.

The package is currently breaking on nightly. This PR causes tests to pass, however I'm unsure if it is correct - especially regarding the removal POST_DROP_USIZE as I can't find much info about it online.

For context, I'm basing this change off of what I saw on servo to support nightly, which appears to likewise remove similar logic.

lib.rs: Fix for changes to macros, and tuple indexing.

tests.rs: Fix for language removal of proc, replaced with move. Replaced depreciated std::task with std::thread

• new build.rs just calls make (importing header files did not seem straight-forward)

Fix for part of #14

It would be nice to get rid of config.c, but I suppose if header files could already be easily included in Rust, it wouldn't need to be there in the first place.

As detailed here files named aux aren't allowed so a git clone fails while creating aux.rs. All it needs is a rename. I would do a pull request but I'm only able to get on my Windows machine right now and I can't exactly clone the repo.

Thanks!

The major hurdle to this that I've found is filling drops:

src/lib.rs +11

![feature(unsafe_no_drop_flag,filling_drop)]

I don't understand filling drops well enough to know how it affects rust-lua. Everything else can probably be worked around though.

I don't think support for lua 5.1 should be dropped, so I think something needs to be decided in how multiple lua versions will work together within rust-lua. Here are a few ideas:

1. separate branch for each lua version
   • denoted by different version scheme in cargo repository
2. separate crate per supported lua version (use lua::lua51;, use lua::lua52;)
3. separate repository for each lua version
   • change crate name to lua51 so a future lua52 crate can be implemented
4. build flags?

Of these, I'd like either 1 or 2, but if you're unwilling to support multiple lua versions, perhaps 3 would be best.

I am fairly new to rust and started playing around with the language very recently. When I tried to use rust-lua with luajit, it compiles fine, but I get the error message: "Must use luaL_newstate() for 64 bit target" As a quick test I added the necessary function signature pub fn luaL_newstate() -> *mut lua_State; and called it instead of the previous newstate function using the custom allocator. Unfortunately the function always returns null and therefore the unwrapping of the Option fails.

I am assuming this problem is somehow related to luajit failing to do the necessary memory allocations, but I currently lack the skills and knowledge to figure out why the allocation fails.

Therefore I wanted to ask if support for luajit is planned for rust-lua, because the performance benefits from luajit are significant.

As talked about at the 1/28/14 rust meetup, there is a serious safety hole. Lua error handling by default uses setjmp/longjmp, which won't fire destructors as it pops the stack. Lua can be compiled with C++, which will make it use throw/catch instead, which will fire Rust destructors, but this still isn't safe. Rust code typically makes the assumption that any premature stack unwinding is due to task failure, and therefore anything on the stack will be thrown away.

Compiling Lua as C++ is significantly better than letting it use setjmp/longjmp. However, Lua is typically only compiled this way when embedded (as source) into a C++ application. Freestanding Lua library compilation, which rust-lua takes advantage of by default, will generally be compiled with the default C behavior. Unfortunately, embedding the Lua source into rust-lua is problematic. Not only does it preclude building a Rust library that is then used in a larger application that itself links against Lua, but also the act of compiling Lua needs some platform-specific knowledge (to turn on a few defines that control behavior).

If we bite the bullet and embed Lua after all, we still have the problem where throwing C++ exceptions through Rust code is not particularly safe. I'm inclined to require Rust functions exposed to Lua to be marked unsafe as a hint that there is an issue here. Beyond that I don't know what to do. Marking every method on State as unsafe is possible, but not something I'd like to do. We also cannot call every Lua C function in protected mode as the act of setting up protected mode may potentially throw an exception.

It's also been pointed out to me that C++ considers it undefined behavior to throw a C++ exception past an extern "C" boundary. This does suggest another alternative, which is to wrap every lua function in a C++ function that catches all exceptions and returns an error code. rust-lua could then call those C++ wrappers (which themselves would be extern "C") and return a Result. This has its own problems, of course, beyond the awkwardness of writing all the C++ wrappers. Not only are there performance implications to consider, but I have no idea how Lua will behave if any Lua functions are called after catching this exception (as this interrupted Lua's expected error handling). Furthermore, there's no good way to re-throw the exception again in order to resume Lua's error handling.

Another option to consider is that we could redefine the macros used to control error handling to invoke whatever code we want. The question is how to get Lua to unwind past its own code, stop when it hits a Rust function, and then resume when the Rust function finishes (and further, how to enforce in the Rust function that it needs to return immediately on any errors).