The `wasmtime` crate currently lives in `crates/api` for historical
reasons, because we once called it `wasmtime-api` crate. This creates a
stumbling block for new contributors.
As discussed on Zulip, rename the directory to `crates/wasmtime`.
This removes the `--nocapture` argument from Rust tests which enables
capturing the output of tests by default, only printing the output if
the test fails. I've seen that this otherwise seems to largely just dump
a very large amount of information to CI and makes it difficult to
diagnose a failure quickly from CI logs since you have to search
backwards to find the reason something failed.
This commit extends our CI to produce release artifacts for the
x86_64-pc-windows-gnu target. This was originally motivate by the [go
extension] where it looks like the Go toolchain primarily interoperates
with MinGW, not with MSVC natively.
The support here turned out to be quite trivial, largely just adding the
configuration to make the release. I don't think we should necessarily
commit to this being a primary platform for Wasmtime at this time
though. If the support here regresses in the future for a
difficult-to-fix reason I think it would be fine to back out the
platform at least temporarily.
Note that this does not add a full test suite for the MinGW target, only
a release builder. This release builder does run tests, but not with
full debug assertions enabled.
[go extension]: https://github.com/bytecodealliance/wasmtime-go/issues/3Closes#1535
* Add AArch64 tests to CI
This commit enhances our CI with an AArch64 builder. Currently we have
no physical hardware to run on so for now we run all tests in an
emulator. The AArch64 build is cross-compiled from x86_64 from Linux.
Tests all happen in release mode with a recent version of QEMU (recent
version because it's so much faster, and in release mode because debug
mode tests take quite a long time in an emulator).
The goal here was not to get all tests passing on CI, but rather to get
AArch64 running on CI and get it green at the same time. To achieve that
goal many tests are now ignored on aarch64 platforms. Many tests fail
due to unimplemented functionality in the aarch64 backend (#1521), and
all wasmtime tests involving compilation are also disabled due to
panicking attempting to generate generate instruction offset information
for trap symbolication (#1523).
Despite this, though, all Cranelift tests and other wasmtime tests
should be runnin on AArch64 through QEMU with this PR. Additionally
we'll have an AArch64 binary release of Wasmtime for Linux, although it
won't be too useful just yet since it will panic on almost all wasm
modules.
* Review comments
* Move most wasmtime tests into one test suite
This commit moves most wasmtime tests into a single test suite which
gets compiled into one executable instead of having lots of test
executables. The goal here is to reduce disk space on CI, and this
should be achieved by having fewer executables which means fewer copies
of `libwasmtime.rlib` linked across binaries on the system. More
importantly though this means that DWARF debug information should only
be in one executable rather than duplicated across many.
* Share more build caches
Globally set `RUSTFLAGS` to `-Dwarnings` instead of individually so all
build steps share the same value.
* Allow some dead code in cranelift-codegen
Prevents having to fix all warnings for all possible feature
combinations, only the main ones which come up.
* Update some debug file paths
We don't need full debug information but rather line tables
(debuginfo=1) should suffice for backtraces if truly necessary. Note
that this doesn't actually work on stable Rust just yet due to it being
an unrelease feature of Cargo. With the Rust release next week though
this'll work on all of stable/beta/nightly.
This commit removes the .NET implementation from Wasmtime.
It now exists at https://github.com/bytecodealliance/wasmtime-dotnet.
Also updates the Wasmtime book to include information about using Wasmtime from
.NET.
* Remove the wasmtime Python extension from this repo
This commit removes the `crates/misc/py` folder and all associated
doo-dads like CI. This module has been rewritten to use the C API
natively and now lives at
https://github.com/bytecodealliance/wasmtime-py as discussed on #1390
This commit fixes an issue where you couldn't actually link to
`wasmtime.dll` via a C compiler because it was missing its import
library, `wasmtime.dll.lib`
Add some crate features to compile out support for these features of the
C API. Avoiding these two features if they're not necessary shaves about
2MB off the final shared object in some local tests!
* Publishing fixes.
* Make WASI a symlink.
* More fixes.
* Cargo doesn't allow dev-dependencies to have optional features.
* Remove the symlink.
* Add WASI as another git submodule.
We've got a cranelift-v0.60.0 release made with the recent
cranelift-v0.60.0 tag, but the release infrastructure is intended to
only get used for wasmtime tags. Let's see if we can coerce github
actions to only releasing for wasmtime tags.
* Remove the old wast and wasm2obj commands.
These are subsumed by the `wasmtime wast` and `wasmtime wasm2obj` commands.
Fixes#827.
* Remove wasm2obj install commands.
... but turn it back on in CI by default. The `binaryen-sys` crate
builds binaryen from source, which is a drag on CI for a few reasons:
* This is quite large and takes a good deal of time to build
* The debug build directory for binaryen is 4GB large
In an effort to both save time and disk space on the builders this
commit adds a `binaryen` feature to the `wasmtime-fuzz` crate. This
feature is enabled specifically when running the fuzzers on CI, but it
is disabled during the typical `cargo test --all` command. This means
that the test builders should save an extra 4G of space and be a bit
speedier now that they don't build a giant wad of C++.
We'll need to update the OSS-fuzz integration to enable the `binaryen`
feature when executing `cargo fuzz build`, and I'll do that once this
gets closer to landing.
This should save us about 3GB of target directory disk space and it may
also be a tiny speed boost. There's no real benefit to using incremental
builds on CI because we're not changing code anyway!
It is too easy to run afoul of yaml syntax with all these colons an asterisks,
e.g. we recently broke the bot like this:
``
YAMLException: unidentified alias ".md" at line 58, column 9:
- *.md
^
at generateError (/home/runner/work/_actions/bytecodealliance/labeler/schedule-fork/dist/index.js:8357:10)
at throwError (/home/runner/work/_actions/bytecodealliance/labeler/schedule-fork/dist/index.js:8363:9)
at readAlias (/home/runner/work/_actions/bytecodealliance/labeler/schedule-fork/dist/index.js:9466:5)
at composeNode (/home/runner/work/_actions/bytecodealliance/labeler/schedule-fork/dist/index.js:9558:20)
at readBlockMapping (/home/runner/work/_actions/bytecodealliance/labeler/schedule-fork/dist/index.js:9226:16)
at composeNode (/home/runner/work/_actions/bytecodealliance/labeler/schedule-fork/dist/index.js:9549:12)
at readBlockSequence (/home/runner/work/_actions/bytecodealliance/labeler/schedule-fork/dist/index.js:9145:5)
at composeNode (/home/runner/work/_actions/bytecodealliance/labeler/schedule-fork/dist/index.js:9548:12)
at readBlockMapping (/home/runner/work/_actions/bytecodealliance/labeler/schedule-fork/dist/index.js:9279:11)
at composeNode (/home/runner/work/_actions/bytecodealliance/labeler/schedule-fork/dist/index.js:9549:12)
```
Ideally, this would be on "labeled" types of pull request events, but that
doesn't work if the pull request is from another fork. For example, see
https://github.com/actions/labeler/issues/12
* Move all examples to a top-level directory
This commit moves all API examples (Rust and C) to a top-level
`examples` directory. This is intended to make it more discoverable and
conventional as to where examples are located. Additionally all examples
are now available in both Rust and C to see how to execute the example
in the language you're familiar with. The intention is that as more
languages are supported we'd add more languages as examples here too.
Each example is also accompanied by either a `*.wat` file which is
parsed as input, or a Rust project in a `wasm` folder which is compiled
as input.
A simple driver crate was also added to `crates/misc` which executes all
the examples on CI, ensuring the C and Rust examples all execute
successfully.
