... 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!
* Store module name on `wasmtime_environ::Module`
This keeps all name information in one place so we dont' have to keep
extra structures around in `wasmtime::Module`.
* rustfmt
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)
```
* Impl different formatters for flags
Rather than forcing only binary formatting of flags types, how about
we implement all relevant traits (`Binary`, `Octal`, `LowerHex`, and
`UpperHex`) and allow the user to pick the most relevant one for their
use case?
Also, we use at least `Octal` and `LowerHex` in a couple of places
in `wasi-common`.
* fmt::Display for flags now inspired by bitflags
Flags is now by default formatted similarly to how
`bitflags` crate does it, namely, `dsync|append (0x11)`. In case
we're dealing with an empty set, we get `empty (0x0)`. Because of
this, any `Octal`, `LowerHex`, etc., formatters are redundant now.
Furthermore, while here, I've rewritten `EMPTY_FLAGS` and `ALL_FLAGS`
(where the former means `0x0` and the latter is the union of all possible
values) to be `const fn empty()` and `const fn all()` where the latter is
an expanded union of primitive representation values out of a macro.
This is again largely inspired by the `bitflags` crate.
* Test fmt::Display for flags
* Fill out API docs on `wasmtime::Module`
Part of #1272
* Apply suggestions from code review
Co-Authored-By: Nick Fitzgerald <fitzgen@gmail.com>
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
* Refactor wasmtime_runtime::Export
Instead of an enumeration with variants that have data fields have an
enumeration where each variant has a struct, and each struct has the
data fields. This allows us to store the structs in the `wasmtime` API
and avoid lots of `panic!` calls and various extraneous matches.
* Pre-generate trampoline functions
The `wasmtime` crate supports calling arbitrary function signatures in
wasm code, and to do this it generates "trampoline functions" which have
a known ABI that then internally convert to a particular signature's ABI
and call it. These trampoline functions are currently generated
on-the-fly and are cached in the global `Store` structure. This,
however, is suboptimal for a few reasons:
* Due to how code memory is managed each trampoline resides in its own
64kb allocation of memory. This means if you have N trampolines you're
using N * 64kb of memory, which is quite a lot of overhead!
* Trampolines are never free'd, even if the referencing module goes
away. This is similar to #925.
* Trampolines are a source of shared state which prevents `Store` from
being easily thread safe.
This commit refactors how trampolines are managed inside of the
`wasmtime` crate and jit/runtime internals. All trampolines are now
allocated in the same pass of `CodeMemory` that the main module is
allocated into. A trampoline is generated per-signature in a module as
well, instead of per-function. This cache of trampolines is stored
directly inside of an `Instance`. Trampolines are stored based on
`VMSharedSignatureIndex` so they can be looked up from the internals of
the `ExportFunction` value.
The `Func` API has been updated with various bits and pieces to ensure
the right trampolines are registered in the right places. Overall this
should ensure that all trampolines necessary are generated up-front
rather than lazily. This allows us to remove the trampoline cache from
the `Compiler` type, and move one step closer to making `Compiler`
threadsafe for usage across multiple threads.
Note that as one small caveat the `Func::wrap*` family of functions
don't need to generate a trampoline at runtime, they actually generate
the trampoline at compile time which gets passed in.
Also in addition to shuffling a lot of code around this fixes one minor
bug found in `code_memory.rs`, where `self.position` was loaded before
allocation, but the allocation may push a new chunk which would cause
`self.position` to be zero instead.
* Pass the `SignatureRegistry` as an argument to where it's needed.
This avoids the need for storing it in an `Arc`.
* Ignore tramoplines for functions with lots of arguments
Co-authored-by: Dan Gohman <sunfish@mozilla.com>
* Temporarily remove support for interface types
This commit temporarily removes support for interface types from the
`wasmtime` CLI and removes the `wasmtime-interface-types` crate. An
error is now printed for any input wasm modules that have wasm interface
types sections to indicate that support has been removed and references
to two issues are printed as well:
* #677 - tracking work for re-adding interface types support
* #1271 - rationale for removal and links to other discussions
Closes#1271
* Update the python extension
* Add tutorial for building and running hello-world.wasm
* Fix issues with directory trees in last commit
* Add more information on various ways of creating .wasm files and running them with Wasmtime
* Fix internal links and add more information on Wasmtime CLI installation
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.
* Exit with a more severe error code if the program traps.
Previously, the wasmtime CLI would return with a regular failure
error code, such as 1 on Unix. However, a program trap indicates a bug
in the program, which can be useful to distinguish from a simple error
status. Check for the trap case, and return an appropriate OS-specific
exit status.
* Use a loop to iterate over the error causes to find Traps.
* Use anyhow's `chain()` iterator.
* For completeness, handle non-Unix and non-Windows platforms too.
* Add a CLI test for a trapping program.
* Replace a manual `.cause` loop with a `.is` call.
* Correct the expected exit status on Windows.
* Use assert_eq/assert_ne so that if these fail, it prints the output.
