Integrate Lightbeam

[eira-fransham]

This PR uses Lightbeam (my current working branch of it https://github.com/Vurich/lightbeam/tree/loops) as the compilation backend for wasmtime. Currently this causes most of the tests to fail, since I haven't implemented any floating-point instructions, br_table, select, globals, or any of the smaller load instructions (such as i32.load8), but some of the tests are succeeding and traps appear to work, which was the main thing I was hoping for since I definitely didn't want to duplicate the trap work done here in Lightbeam proper. There's currently an intermittent memory access violation that causes the program to crash when run without --test-threads 1, I don't have a good way of finding out what is causing this because memcheck gives several thousand errors, presumably because of deliberate faults being triggered by the compiled WebAssembly.

Also, since Lightbeam implements signature checking in an incompatible way I just have it panic when trying to access the function table.

To test, run cargo test --features lightbeam -- --test-threads 1

[eira-fransham]

Any idea why the build fails? It looks like it's not checking the lightbeam submodule out but it's working when I try to check the repo out in a new folder

[lqd]

Would using git dependencies in Cargo.toml instead of git submodules make it easier / make it work ?

[eira-fransham]

Yes, it would, but I thought it would be easier to keep the two repositories in sync if I included it as a submodule

[maxmcd]

It looks like your submodule is pointing to a local directory. Should likely be pointed at the git repo.

[eira-fransham]

Fixed

[sunfishcode]

Overall, this is looking good! There's certainly lots of things here that will evolve over time, but overall things look headed in a good direction.

[sunfishcode]

This makes sense for now, though if you want, I think it could also make sense to just move lightbeam into wasmtime for now. That'd make it easier to manages changes that stradle the boundary here.

[eira-fransham]

Now that Lightbeam is passing the spec tests, I've updated this branch for the latest master, although debuginfo won't work since we just ignore the flag. I've also cleaned it up based on your feedback.

The main problem with merging this is that there's no contemporary Rust compiler that this works on. The latest nightly broke the plugin version of dynasm and the more recent macro version of dynasm doesn't seem to work inside macro_rules (but it could be that the syntax changed, I didn't look too deeply into it). I'm going to dig into it a bit and if I can't get it to work I'll just start rolling my own assembler as my next task, I wanted to do so anyway because dynasm doesn't really allow for abstraction at all.

EDIT: Fixed the problem with dynasm, it turns out that it was looking for tt for some of the elements where I was capturing ident in the macro_rules! macro args. I still want to replace dynasm eventually, mind.

[sunfishcode]

Sounds good. Let's merge this now, and development can proceed from there! The CI failure is fixed on master already, so we can ignore that here.