56ce6e9c9f
* 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.
Wasmtime: a WebAssembly Runtime.
Wasmtime is a standalone wasm-only optimizing runtime for WebAssembly and WASI. It runs WebAssembly code outside of the Web, and can be used both as a command-line utility or as a library embedded in a larger application.
To get started, visit wasmtime.dev.
There are Rust, C, and C++ toolchains that can compile programs with WASI. See the WASI intro for more information, and the WASI tutorial for a tutorial on compiling and running programs using WASI and wasmtime, as well as an overview of the filesystem sandboxing system.
Wasmtime passes the WebAssembly spec testsuite. To run it, update the
spec_testsuite submodule with git submodule update --remote, and it will
be run as part of cargo test.
Wasmtime does not yet implement Spectre mitigations, however this is a subject of ongoing research.
Additional goals for Wasmtime include:
- Support a variety of host APIs (not just WASI), with fast calling sequences, and develop proposals for additional API modules to be part of WASI.
- Implement the proposed WebAssembly C API.
- Facilitate testing, experimentation, and development around the Cranelift and Lightbeam JITs.
- Develop a native ABI used for compiling WebAssembly suitable for use in both JIT and AOT to native object files.
Including Wasmtime in your project
Wasmtime exposes an API for JIT compilation through the wasmtime-jit subcrate, which depends on wasmtime-environ and wasmtime-runtime for the ABI and runtime support respectively. However, this API is not documented and subject to change. Please use at your own risk!
Build the individual crates as such:
cargo build --package wasmtime-jit
Wasmtime does not currently publish these crates on crates.io. They may be included as a git dependency, like this:
[dependencies]
wasmtime-environ = { git = "https://github.com/CraneStation/wasmtime", rev = "somecommithash" }
wasmtime-runtime = { git = "https://github.com/CraneStation/wasmtime", rev = "somecommithash" }
wasmtime-jit = { git = "https://github.com/CraneStation/wasmtime", rev = "somecommithash" }
All three crates must be specified as dependencies for wasmtime-jit to build correctly, at the moment.
It's Wasmtime.