Commit Graph

2 Commits

Author SHA1 Message Date
Josh Triplett
56ce6e9c9f Migrate from failure to thiserror and anyhow (#436)
* 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.
2019-11-04 20:43:25 -08:00
Alex Crichton
d1b1500d19 Add an example #[wasmtime] Rust macro (#283)
This commit adds a `wasmtime-rust` crate to the `misc` folder next to
the previously added Python extension. The intention is that this
showcases loading a WebAssembly file natively in Rust and how with an
attribute macro it can feel lightweight in terms of boilerplate.

The macro itself is pretty non-featureful today beyond the bare bones to
get anything working, but there's all sorts of possibilities like
JIT-compiled entry stubs we could eventually do with all the type
information!
2019-08-19 19:45:42 +02:00