This is important PR to fix potential memory leaks with extra data.

I use extra objects a lot and found case when memory leaks:

let extra = Arc::new(Mutex::new(0));
let state = State::new();
state.set_extra(Some(Box::new(extra.clone())));
let thread = state.new_thread();
thread.set_extra(Some(Box::new(extra.clone())));
drop(thread); // extra pointer is lost here
drop(state);

The reason why pointer is lost:

pub fn new_thread(&mut self) -> State {
  unsafe {
    // `owned` flag doesn't set here!
    let mut state = State::from_ptr(ffi::lua_newthread(self.L));
    state.reset_extra();
    state
  }
}

 impl Drop for State {
   fn drop(&mut self) {
    if self.owned {
       let _ = self.set_extra(None);
       unsafe { ffi::lua_close(self.L) }
     }
   }

I've add three origins of a reference to a state:

1. Owned - when new state created
2. Thread - when new thread created (like Owned, but close never be called)
3. Restored - when state restored from a reference

I don't think we have to implement automatic cleanup by Lua's GC, because:

1. It takes runtime cost
2. I am convinced that if user attached some extra, they want to explore it later, and keep original State of thread
3. It will hard to debug (simply to take panics at empty extra unwrapping)
4. I'm not sure it's possible with thread object

I've checked this PR. It's 100% backward compatible.

1. It will complain about "File not found" until I put the folder "lua-5.3.0" in "(project dir)\target\debug\build\lua-186a5bc53332bb1e\out"
2. It doesn't build anyway, gives errors like this:

D:\PROJECTS\Rust\lua_test>cargo build --verbose
   Compiling lua v0.0.8 (https://github.com/jcmoyer/rust-lua53#f0835d4a)
     Running `rustc C:\Users\REVERSE\.cargo\git\checkouts\rust-lua53-337f374af0243c90\master\src\lib.rs --crate-name lua
 --crate-type lib -g -C metadata=186a5bc53332bb1e -C extra-filename=-186a5bc53332bb1e --out-dir D:\PROJECTS\Rust\lua_tes
t\target\debug\deps --emit=dep-info,link -L dependency=D:\PROJECTS\Rust\lua_test\target\debug\deps -L dependency=D:\PROJ
ECTS\Rust\lua_test\target\debug\deps --extern libc=D:\PROJECTS\Rust\lua_test\target\debug\deps\liblibc-144c435538abd757.
rlib --extern bitflags=D:\PROJECTS\Rust\lua_test\target\debug\deps\libbitflags-dd68b8369bcd8ff0.rlib -Awarnings -L nativ
e=D:\PROJECTS\Rust\lua_test\target\debug\build\lua-186a5bc53332bb1e\out\lua-5.3.0\src -l static=lua`
       Fresh libc v0.1.10
       Fresh bitflags v0.1.1
C:\Users\REVERSE\.cargo\git\checkouts\rust-lua53-337f374af0243c90\master\src\ffi/mod.rs:295:5: 295:9 error: file not fou
nd for module `glue`
C:\Users\REVERSE\.cargo\git\checkouts\rust-lua53-337f374af0243c90\master\src\ffi/mod.rs:295 mod glue;
                                                                                                ^~~~
C:\Users\REVERSE\.cargo\git\checkouts\rust-lua53-337f374af0243c90\master\src\ffi/mod.rs:295:5: 295:9 help: name the file
 either glue.rs or glue/mod.rs inside the directory "C:\\Users\\REVERSE\\.cargo\\git\\checkouts\\rust-lua53-337f374af024
3c90\\master\\src\\ffi"
Could not compile `lua`.

Caused by:
  Process didn't exit successfully: `rustc C:\Users\REVERSE\.cargo\git\checkouts\rust-lua53-337f374af0243c90\master\src\
lib.rs --crate-name lua --crate-type lib -g -C metadata=186a5bc53332bb1e -C extra-filename=-186a5bc53332bb1e --out-dir D
:\PROJECTS\Rust\lua_test\target\debug\deps --emit=dep-info,link -L dependency=D:\PROJECTS\Rust\lua_test\target\debug\dep
s -L dependency=D:\PROJECTS\Rust\lua_test\target\debug\deps --extern libc=D:\PROJECTS\Rust\lua_test\target\debug\deps\li
blibc-144c435538abd757.rlib --extern bitflags=D:\PROJECTS\Rust\lua_test\target\debug\deps\libbitflags-dd68b8369bcd8ff0.r
lib -Awarnings -L native=D:\PROJECTS\Rust\lua_test\target\debug\build\lua-186a5bc53332bb1e\out\lua-5.3.0\src -l static=l
ua` (exit code: 101)

As we can see the "glue" module isn't there.

Is there any chance we could get an example showing how to create a (full) userdata containing a rust struct and correctly set up a metatable to call methods on it? I seem to be getting a bunch of weird segfaults, probably because I'm doing something wrong.

I think @jugglerchris was doing some work with userdata, so tagging him here.

On master, glue is compiled for the target platform. But since it generates glue.rs, it needs to be executable on the host platform instead.

This patch changes build.rs, so that glue is build for the $HOST platform instead of the $TARGET platform.

Is there any plans on supporting cross-compiling? I'm writing a program right now that I would like to cross-compile to many different targets, but I'm having trouble getting the lua crate to compile. I see the other issues about compilation, but this is a slightly different problem.

I tried re-writing build.rs myself to see if I could get cross-compiling to work, but I ran into a problem (which is more of Cargo's fault). First, the build script itself is always is compiled for the host as the target, so we can't rely on cfg!(target_os) to determine how to compile Lua. Instead we can use the TARGET environment variable. However, the glue program needs to be compiled natively as well, since we run it immediately. I tried compiling Lua twice; once for glue, and once for the crate, but glue.rs is put in the wrong place because the value of env!("OUT_DIR") in build.rs does not match env!("OUT_DIR") in src/ffi/mod.rs since they are under different target directories.

Any advice on how to solve this? If I do the compilation steps by hand, I have successfully compiled the crate for Windows from on Linux with mingw-gcc, for example.

Also, there needs to be a mechanism of specifying the gcc to pass to make, since in many cases the system default gcc will not be used during cross-compilation.

This commit splits the lua crate into two: the original lua crate and a lua_sys crate that contains just the raw FFI bindings to Lua. This addresses issue #51.

Features

Since the lua-sys crate can be used independently, it was a minimal amount of effort to also provide a no_std feature for lua_sys, which disables using the standard library for those that don't want it. CString is used in one place, and as a monkey patch added the rcstring crate as an alternative for the one function call. There may be a better solution to this.

Backwards-incompatible changes

Since the ffi module is removed, dependent crates currently using the lua::ffi module will break. In addition, the recently added lua::libc alias is also gone, since lua no longer depends on libc as lua_sys does instead.

These modules are now available as lua::lua_sys and lua::lua_sys::libc. We may want to provide better aliases for these, perhaps for BC sake. We may want lua::sys and lua::libc, or lua::ffi and lua::libc to be aliases for lua_sys modules.

Minor changes

Moved bitflags and libc dependencies to lua-sys, and updated bitflags to version ~0.7.

Stable PR for #48. Benchmarks not included here, but much like #52 there is not really a measurable difference in speed due to the change.

In the name of simplicity, the current implementation returns allocations with the same alignment as usize (4 or 8 bytes). According to my research, GCC and MSVC's mallocs both return allocations with an alignment double that, but it would require 16 bytes of overhead per allocation and additional bookkeeping I have not yet implemented to be able to satisfy this alignment. I don't know of any standard C type that actually requires 16-byte alignment.

Hi,

is it possible to update the last version of rust-lua53 on crates.io please ?

It will allow project to compile with the latest improvement (e.g: https://github.com/Gigoteur/PX8)

Thank you

Adding #[must_use] to ThreadStatus means that if the result of a method that returns it is ignored, a warning is printed, much like if a std::result::Result is unused.

The change to from_c_int is to simplify all the .unwrap() calls and provide a more descriptive panic message.

Fixes #46

I've updated:

• All of is_ methods, because it never change the state
• Some to_ methods, which returns integers, bools or c-function pointer

I didn't change group of check_ and opt_, because it can raise error which will mutate state.

There are two related sets of changes in this patch:

1. Use the length-based variants of string functions where available. This reduces allocations and allows embedding nulls in strings.
2. Return references from string functions rather than owned Strings. This reduces allocations in cases where the returned result is not actually used, and the old behavior can be gained by appending .to_owned() to call sites.
   • Based on the Lua source, typename_of and typename_at return 'static strings.

I think the first point is pretty important, but the second is somewhat opinion-based. Thoughts?

Also, I should point out I here changed to_str to use luaL_tolstring, which converts more types of things to strings, and doesn't edit the stack in-place. Maybe this isn't desired.

Hi, when I try to compile the crate I do get the following error:

--- stdout
cargo:rustc-link-lib=static=lua
OPT_LEVEL = Some("0")
TARGET = Some("x86_64-pc-windows-gnu")
HOST = Some("x86_64-pc-windows-gnu")
TARGET = Some("x86_64-pc-windows-gnu")
TARGET = Some("x86_64-pc-windows-gnu")
HOST = Some("x86_64-pc-windows-gnu")
CC_x86_64-pc-windows-gnu = None
CC_x86_64_pc_windows_gnu = None
HOST_CC = None
CC = None
TARGET = Some("x86_64-pc-windows-gnu")
HOST = Some("x86_64-pc-windows-gnu")
CFLAGS_x86_64-pc-windows-gnu = None
CFLAGS_x86_64_pc_windows_gnu = None
HOST_CFLAGS = None
CFLAGS = None
DEBUG = Some("true")
make -e -f "C:/Users/Tyde/.cargo/git/checkouts/rust-lua53-382fc6466662b050/c855949/lua-source/src/Makefile" "LUA_A=lua53.dll" "LUA_T=lua.exe" \
        "AR=gcc.exe -shared -o" "RANLIB=strip --strip-unneeded" \
        "SYSCFLAGS=-DLUA_BUILD_AS_DLL" "SYSLIBS=" "SYSLDFLAGS=-s" lua.exe
make[1]: Entering directory `/c/Users/Tyde/rustws/lua_interop/target/debug/build/lua-400f40c450b96a19/out'
make[1]: Leaving directory `/c/Users/Tyde/rustws/lua_interop/target/debug/build/lua-400f40c450b96a19/out'

--- stderr
make[1]: *** No rule to make target `lua.c', needed by `lua.o'.  Stop.
make.exe": *** [mingw] Error 2
thread 'main' panicked at 'Error: The command
        "make" "-e" "-f" "C:\\Users\\Tyde\\.cargo\\git\\checkouts\\rust-lua53-382fc6466662b050\\c855949\\lua-source/src\\Makefile" "mingw"
did not run successfully.', C:\Users\Tyde\.cargo\git\checkouts\rust-lua53-382fc6466662b050\c855949\build.rs:176:19
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

this error message seems to indicate, that the makefile isn't able to find lua.c. I also tried running that exact make task in the lua-source/src/ folder and it seems to work here. Is there something needed to allow the makefile to find lua.c?

I've used this crate for some time in the past (about 2 years ago), and all was working normally. But now I can't build a simple test program using this crate.

My config: Win 10x64, MSYS2 x64, toolchain: stable-x86_64-pc-windows-gnu

Here is the log:

$ cargo build
   Compiling lua_test v0.1.0 (D:\Revertron\Projects\Rust\lua_test)
error: linking with `gcc` failed: exit code: 1
  |
  = note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\crt2.o" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "-L" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\lua_test-c8db8b5fe463ccb1.18vb1nw6xzzszu3f.rcgu.o" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\lua_test-c8db8b5fe463ccb1.2h2k0kvqqyduge4s.rcgu.o" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\lua_test-c8db8b5fe463ccb1.2pwao4e83g6308hf.rcgu.o" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\lua_test-c8db8b5fe463ccb1.3r5cez8bf78l97s3.rcgu.o" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\lua_test-c8db8b5fe463ccb1.4i3gz3t8l5j37k7b.rcgu.o" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\lua_test-c8db8b5fe463ccb1.4is8pypstf8vbmpm.rcgu.o" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\lua_test-c8db8b5fe463ccb1.53ijts5nf69s2qot.rcgu.o" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\lua_test-c8db8b5fe463ccb1.foawjxtap1lut4e.rcgu.o" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\lua_test-c8db8b5fe463ccb1.gna1g8vwo8ci689.rcgu.o" "-o" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\lua_test-c8db8b5fe463ccb1.exe" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\lua_test-c8db8b5fe463ccb1.72s9dujwu2npttc.rcgu.o" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps" "-L" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\build\\lua-4f4e7939f824e790\\out" "-L" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-Wl,-Bstatic" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\liblua-f9dc39d012cc8318.rlib" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\libbitflags-e3621cc75072713c.rlib" "D:\\Revertron\\Projects\\Rust\\lua_test\\target\\debug\\deps\\liblibc-2b61f345c31b1aed.rlib" "-Wl,--start-group" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd-f5a6c065b93e90ae.rlib" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libpanic_unwind-56a67334685ce97a.rlib" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libunwind-068d91706ea7cee4.rlib" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liblibc-3a5d444c975b6977.rlib" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc_system-036d09bcf40b669f.rlib" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc-8c0a9404ebc7532a.rlib" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcore-0cf58042c647ffe2.rlib" "-Wl,--end-group" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-e76a9ac5393717f1.rlib" "-Wl,-Bdynamic" "-ladvapi32" "-lws2_32" "-luserenv" "-lshell32" "-Wl,-Bstatic" "-lgcc_eh" "-lpthread" "-Wl,-Bdynamic" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-lmsvcrt" "-luser32" "-lkernel32" "C:\\Users\\Revertron\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o"
  = note: D:\Revertron\Projects\Rust\lua_test\target\debug\deps\liblua-f9dc39d012cc8318.rlib(liolib.o): In function `luaopen_io':
          C:/Users/Revertron/.cargo/registry/src/github.com-1ecc6299db9ec823/lua-0.0.10/lua-source/src/liolib.c:763: undefined reference to `__imp___acrt_iob_func'
          C:/Users/Revertron/.cargo/registry/src/github.com-1ecc6299db9ec823/lua-0.0.10/lua-source/src/liolib.c:764: undefined reference to `__imp___acrt_iob_func'
          C:/Users/Revertron/.cargo/registry/src/github.com-1ecc6299db9ec823/lua-0.0.10/lua-source/src/liolib.c:765: undefined reference to `__imp___acrt_iob_func'
          D:\Revertron\Projects\Rust\lua_test\target\debug\deps\liblua-f9dc39d012cc8318.rlib(ldblib.o): In function `db_debug':
          C:/Users/Revertron/.cargo/registry/src/github.com-1ecc6299db9ec823/lua-0.0.10/lua-source/src/ldblib.c:405: undefined reference to `__imp___acrt_iob_func'
          C:/Users/Revertron/.cargo/registry/src/github.com-1ecc6299db9ec823/lua-0.0.10/lua-source/src/ldblib.c:405: undefined reference to `__imp___acrt_iob_func'
          D:\Revertron\Projects\Rust\lua_test\target\debug\deps\liblua-f9dc39d012cc8318.rlib(ldblib.o):C:/Users/Revertron/.cargo/registry/src/github.com-1ecc6299db9ec823/lua-0.0.10/lua-source/src/ldblib.c:406: more undefined references to `__imp___acrt_iob_func' follow


error: aborting due to previous error

error: Could not compile `lua_test`.

To learn more, run the command again with --verbose.

This example for function State::new_userdata_typed is only correct if MyStruct does not have a destructor. The correct way to move a value into an uninitialized location is std::ptr::write

The given example:

unsafe { *state.new_userdata_typed() = MyStruct::new(...); }
state.set_metatable_from_registry("MyStruct");

When compiling a dll via cargo targeting stable-x86_64-pc-windows-gnu the linker fails to include the correct functions. Instead it only links lua funcitons in the dll.

I came across this when trying to compile the as-lua-lib example. The resultant dll only contains functions prefixed with "lua_", "luaL_", or "luaopen_". Notably missing is the "luaopen_mathx" function required for requiring the library from lua.

I can confirm that the same setup does indeed correctly link when the lua crate is omitted from the compilation. Likewise, the functions are included when compiling with the stable-x86_64-pc-windows-msvc target.

gist example

This is a separate error from #84. This occurs on both OS X and Linux. In the code snippet below: serpent is a regular Lua module and lfs (luafilesystem) is a C module.

extern crate lua;

fn main() {
  let mut state = lua::State::new();
    state.open_libs();
    state.do_string("
    print('hello')

    if not pcall(function() require('serpent') end) then
      print('error loading serpent')
    else
        spt = require('serpent')
        print('serpent successfully loaded')
    end

    local status, err = pcall(function() require('lfs') end)
    print(err)


    ");
}

On Linux it gives the following error:

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/rlua`
hello
serpent successfully loaded
error loading module 'lfs' from file '/home/deepak/lua53/lib/lua/5.3/lfs.so':
        /home/deepak/lua53/lib/lua/5.3/lfs.so: undefined symbol: lua_gettop

On OS X (after fixing #84), it gives the following error:

  Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/rlua`
hello
serpent successfully loaded
error loading module 'lfs' from file '/Users/deepak/Downloads/lua53/lib/lua/5.3/lfs.so':
        dlopen(/Users/deepak/Downloads/lua53/lib/lua/5.3/lfs.so, 6): Symbol not found: _lua_settable
  Referenced from: /Users/deepak/Downloads/lua53/lib/lua/5.3/lfs.so
  Expected in: flat namespace
 in /Users/deepak/Downloads/lua53/lib/lua/5.3/lfs.so

This is just a skeleton code for #82

Currently, it's mostly unimplemented I'm sharing it with you so you can take a glance and give some recommendations before I've written tons of boilerplate code.

The major issue is error handling. Currently, we panic on error because can't propagate it through ToLua trait.

It uses quick_error for reducing boilerplate for errors, I can remove it if you wish. Also, now I see that I should reformat code to 2-space indent, but that's an easy part.