This commit simplifies the build script slightly for generating tests by
doing a few dull refactorings:
* Leaves formatting to `rustfmt`
* Extract bulk of code execution into a top-level shared `run_wast`
function so each test is a one-liner
* Use `anyhow` for errors both in the script and in tests
This commit switches the beta/nightly tests to happen on Ubuntu instead
of macOS. Turns out GitHub Actions has scheduling limitations on macOS
that limit repositories to 5 concurrent jobs per repository, so let's
reduce the load a bit by running more builds on Linux than mac.
We needed a workaround when using wabt on old Linux distros due to using
old versions of `strtof`. With the switch to `wat`, we no longer need
these workarounds.
This commit implements registering unwind information for JIT functions on
Windows so that the operating system can both walk and unwind stacks containing
JIT frames.
Currently this only works with Cranelift as lightbeam does not emit unwind
information yet.
This commit also resets the stack guard page on Windows for stack overflow
exceptions, allowing reliable stack overflow traps.
With these changes, all previously disabled test suite tests (not including
the multi-value tests) on Windows are now passing.
Fixes#291.
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.
This commit migrates wasmtime's CI infrastructure from Azure Pipelines
to Github Actions. Using Github Actions has a few benefits over other
offerings:
* Being natively integrated with Github means that there's no degree of
user account configuration or access control management, it's all
inherent via already existing Github permissions.
* Github Actions gives 20 parallel builders instead of Azure's 10 by
default, which is a nice boost to have!
Overall I've found Github Actions to feel a bit cleaner than Azure
Pipelines as well. Subjectively I've found the configuration to be more
readable and more pleasant to work with, although they're both just as
"powerful" I think. Additionally Github Actions has been pretty solid in
my own personal testing for a number of other projects.
The main trickiness with wasmtime's CI is the rolling `dev` release of
the master branch as well as binary releases for tags. Github Actions
doesn't have quite as much built in functionality as Azure Pipelines,
but Github Actions does have a nice feature where you can define the
code for an action locally rather than only using built-in actions.
This migration adds three local actions with some associated JS code to
run the action (currently it looks like it basically requires JS)
* An `install-rust` action papers over the gotchas about installing
Rust, allowing Rust installation to be a one-liner in the configuration.
* A `binary-compatible-builds` action allows easily configuring the
wheels and the binaries to be "more binary compatible" and handles
things like compilation flags on OSX and Windows while handling the
`centos:6` container on Linux.
* The `github-release` action is the logic using the `@actions/github`
JS package to orchestrate the custom way we manage rolling releases,
ensuring that a new release is made for the master branch under `dev`
(deleting the previous tag/release ahead of time) and then also
manages tagged releases by uploading them there.
I'm hoping that most of the inline actions here will largely go away.
For example `install-rust` should be simply `rustup update $toolchain`
once various environment issues are fixed on Github Actions runner
images. Additionally `github-release` will ideally migrate to something
like https://github.com/actions/create-release or similar once it has
enough functionality. I'm also hoping that the maintenance in the
meantime of these actions is pretty low-cost, but if it becomes an issue
we can look into other solutions!
* 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.
This commit syncs `wasmtime-wasi` crate with the latest refactoring
applied to `wasi-common` crate. Namely, `wasm32` is replaced with
two modules: `wasi` and `wasi32`. This change can be tracked via
CraneStation/wasi-common#151.
* [wasmtime-api] run example as tests
* Update wasmtime-api/tests/examples.rs
Co-Authored-By: Nick Fitzgerald <fitzgen@gmail.com>
* disable multi example test on windows
This commit adds the skeleton of a new set of documentation for
`wasmtime` in the existing `docs` directory. This documentation is
organized and compiled with [mdbook] which the Rust project uses for
most of its own documentation as well. At a previous meeting we
brainstormed a rough skeleton of what the documentation in this book
would look like, and I've transcribed that here for an example of how
this is rendered and how it can be laid out. No actual documentation is
written yet.
This commit also additionally adds necessary support to auto-publish
both this book documentation and API documentation every time a commit
is pushed to the `master` branch. All HTML will be automatically pushed
to the `gh-pages` branch so long as the CI passes, and this should get
deployed to https://cranestation.github.io/wasmtime.
I've done a few dry-runs and I think this'll all work, but we'll likely
tweak a few things here and there after running this through CI to make
sure everything looks just as we'd like. My hope though is that after
this lands we can start actually filling out all the documentation and
being able to review it as well.
[mdbook]: https://crates.io/crates/mdbook
cargo test will test examples that have a "main.rs", but in this case,
the example requires manual compilation as a wasm module, and doesn't
build as a standalone program. Rename it to "demo.rs".
Fix what looks like a copy-paste issue in wasmtime-api/src/module.rs,
which led to calling reserve_exact on one vector before pushing that
many elements into another.
wasmtime-wasi-c contains many bindgen-generated symbols like
bindgen_test_layout___wasi_event_t___wasi_event_u___wasi_event_u_fd_readwrite_t
that contain triple-underscores in them. rustc doesn't consider those
names snake-case and generates extensive warnings about them. Suppress
those warnings with allow(non_snake_case).
* Add more SIMD spec tests
Also provides a helper, extract_name, for building the names needed for the generated code
* Use `cargo test ... -- --nocapture` to see test errors in CI
* Use OS-independent paths for WAST files
* Ignore 'skip-stack-guard-page'
* Temporarily disable SIMD tests
* Re-enable SIMD spec tests and only disable on Windows temporarily
This PR updates `wasmtime_wasi` crate by adjusting `poll_oneoff`'s
signature to that introduced in `wasi_common` in
CraneStation/wasi-common#137. This change is required in order to
fix#440.
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.
* Don't run the spec_testsuite tests if the submodule isn't checked out.
This way, if someone checks out the repository without checking out the
submodules, they can still run "cargo test".
Also, fix a warning in the generated test runner code.
* Print a message if the spec_testsuite submodule is not enabled.
* Move the `#[cfg(test)]` to the top-level `mod`.
* Update the README.md.
Feature the wasmtime.dev website, update WASI content.
With Lightbeam moving into the Wasmtime repo, it's no longer necessary
to use git submodules to build Wasmtime.
