This commit bumps Cranelift to 0.49.0 and target-lexicon to 0.9.0 to fix the
failing build to due an updated faerie crate that violated semver with an
updated 0.9.0 target-lexicon dependency.
Fixes#491.
* Migrate from failure to thiserror and anyhow
The failure crate invents its own traits that don't use
std::error::Error (because failure predates certain features added to
Error); this prevents using ? on an error from failure in a function
using Error. The thiserror and anyhow crates integrate with the standard
Error trait instead.
This change does not attempt to semantically change or refactor the
approach to error-handling in any portion of the code, to ensure that
the change remains straightforward to review. Modules using specific
differentiated error types move from failure_derive and derive(Fail) to
thiserror and derive(Error). Modules boxing all errors opaquely move
from failure::Error to anyhow. Modules using String as an error type
continue to do so. Code using unwrap or expect continues to do so.
Drop Display implementations when thiserror can easily derive an
identical instance.
Drop manual traversal of iter_causes; anyhow's Debug instance prints the
chain of causes by default.
Use anyhow's type alias anyhow::Result<T> in place of
std::result::Result<T, anyhow::Error> whenever possible.
* wasm2obj: Simplify error handling using existing messages
handle_module in wasm2obj manually maps
cranelift_codegen::isa::LookupError values to strings, but LookupError
values already have strings that say almost exactly the same thing.
Rely on the strings from cranelift.
* wasmtime: Rely on question-mark-in-main
The main() wrapper around rmain() completely matches the behavior of
question-mark-in-main (print error to stderr and return 1), so switch to
question-mark-in-main.
* Update to walrus 0.13 and wasm-webidl-bindings 0.6
Both crates switched from failure to anyhow; updating lets us avoid a
translation from failure to anyhow within wasmtime-interface-types.
Accidentally left removed #434 when I meant to add it back in! Updates
the `wast` crate dependency and adds support for translating
`v128.const` instructions to a `RuntimeValue`
Closes#441
* Switch lightbeam from `wabt` to `wast`
Switch from a C++-based `*.wat` parser to a Rust-based parser
* Remove unneeded `wabt` dev-dependency from wasmtime-api
* Rewrite `wasmtime-wast` crate with `wast-parser`
This commit moves the `wasmtime-wast` crate off the `wabt` crate on to
the `wast-parser` crate which is a Rust implementation of a `*.wast` and
`*.wat` parser. The intention here is to continue to reduce the amount
of C++ required to build wasmtime!
* Use new `wat` and `wast` crate names
* deps: bump wasmparser to 0.39.2
This has a bug fix for multi-value Wasm validation that is required for getting
the spec tests passing.
https://github.com/yurydelendik/wasmparser.rs/pull/135
* Update cranelift to 0.46.1 to get multi-value Wasm support
The `cranelift_wasm` APIs had to change a little bit to maintain state necessary
when translating multi-value Wasm blocks. The `translate_module` function now
returns a `ModuleTranslationState` that is borrowed during each function's
translation.
* Enable multi-value proposal's spec tests
This enables all the Wasm multi-value proposal's spec tests other than the ones
that rely on functions having more return values than registers available on the
target. That is not supported by cranelift yet.
* wasmtime-interface-types: always use multi-value Wasm
And remove the return pointer hacks that work around the lack of multi-value.
This change adds an `--enable-simd` flag to the binaries in this project. This allows the ISA `enable_simd` flag to be set and to configure the validation configuration used by wasmparser to allow SIMD instructions.
* Simple module compilation cache
* Fix base64 encoding bug
* Use warn! everywhere in cache system
* Remove unused import
* Temporary workaround for long path on Windows
* Remove unused import for non-windows builds
* Add command line argument to enable cache system + apply minor review feedback
Even though this somehow passed on Travis on [the
PR](https://github.com/CraneStation/wasmtime/pull/209), it fails on
Travis on master, and I can reproduce the failure.
The failure is on spec_testsuite/names.wast:
```
$ RUST_BACKTRACE=1 target/debug/wast spec_testsuite/names.wast
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: FromUtf8Error { bytes: [255], error: Utf8Error { valid_up_to: 0, error_len: Some(1) } }', src/libcore/result.rs:999:5
stack backtrace:
[...]
9: core::result::Result<T,E>::unwrap
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/result.rs:800
10: wabt::script::jstring_to_rstring
at [...]/.cargo/registry/src/github.com-1ecc6299db9ec823/wabt-0.8.0/src/script/mod.rs:261
11: wabt::script::parse_action
at [...]/.cargo/registry/src/github.com-1ecc6299db9ec823/wabt-0.8.0/src/script/mod.rs:274
12: wabt::script::ScriptParser<F32,F64>::next
at [...]/.cargo/registry/src/github.com-1ecc6299db9ec823/wabt-0.8.0/src/script/mod.rs:504
13: wasmtime_wast::wast::WastContext::run_buffer
at wasmtime-wast/src/wast.rs:202
14: wasmtime_wast::wast::WastContext::run_file
at wasmtime-wast/src/wast.rs:472
15: wast::main
at src/wast.rs:107
[...]
```
