* Redesign Wasmtime's CLI
This commit follows through on discussion from #6741 to redesign the
flags that the `wasmtime` binary accepts on the CLI. Almost all flags
have been renamed/moved and will require callers to update. The main
motivation here is to cut down on the forest of options in `wasmtime -h`
which are difficult to mentally group together and understand.
The main change implemented here is to move options behind "option
groups" which are intended to be abbreviated with a single letter:
* `-O foo` - an optimization or performance-tuning related option
* `-C foo` - a codegen option affecting the compilation process.
* `-D foo` - a debug-related option
* `-W foo` - a wasm-related option, for example changing wasm semantics
* `-S foo` - a WASI-related option, configuring various proposals for example
Each option group can be explored by passing `help`, for example `-O
help`. This will print all options within the group along with their
help message. Additionally `-O help-long` can be passed to print the
full comment for each option if desired.
Option groups can be specified multiple times on the command line, for
example `-Wrelaxed-simd -Wthreads`. They can also be combined together
with commas as `-Wrelaxed-simd,threads`. Configuration works as a "last
option wins" so `-Ccache,cache=n` would end up with a compilation
cache disabled.
Boolean options can be specified as `-C foo` to enable `foo`, or they
can be specified with `-Cfoo=$val` with any of `y`, `n`, `yes`, `no`,
`true`, or `false`. All other options require a `=foo` value to be
passed and the parsing depends on the type.
This commit additionally applies a few small refactorings to the CLI as
well. For example the help text no longer prints information about wasm
features after printing the option help. This is still available via
`-Whelp` as all wasm features have moved from `--wasm-features` to `-W`.
Additionally flags are no longer conditionally compiled in, but instead
all flags are always supported. A runtime error is returned if support
for a flag is not compiled in. Additionally the "experimental" name of
WASI proposals has been dropped in favor of just the name of the
proposal, for example `--wasi nn` instead of `--wasi-modules
experimental-wasi-nn`. This is intended to mirror how wasm proposals
don't have "experimental" in the name and an opt-in is required
regardless.
A full listing of flags and how they have changed is:
| old cli flag | new cli flag |
|-----------------------------------------------|-------------------------------------------------|
| `-O, --optimize` | removed |
| `--opt-level <LEVEL>` | `-O opt-level=N` |
| `--dynamic-memory-guard-size <SIZE>` | `-O dynamic-memory-guard-size=...` |
| `--static-memory-forced` | `-O static-memory-forced` |
| `--static-memory-guard-size <SIZE>` | `-O static-memory-guard-size=N` |
| `--static-memory-maximum-size <MAXIMUM>` | `-O static-memory-maximum-size=N` |
| `--dynamic-memory-reserved-for-growth <SIZE>` | `-O dynamic-memory-reserved-for-growth=...` |
| `--pooling-allocator` | `-O pooling-allocator` |
| `--disable-memory-init-cow` | `-O memory-init-cow=no` |
| `--compiler <COMPILER>` | `-C compiler=..` |
| `--enable-cranelift-debug-verifier` | `-C cranelift-debug-verifier` |
| `--cranelift-enable <SETTING>` | `-C cranelift-NAME` |
| `--cranelift-set <NAME=VALUE>` | `-C cranelift-NAME=VALUE` |
| `--config <CONFIG_PATH>` | `-C cache-config=..` |
| `--disable-cache` | `-C cache=no` |
| `--disable-parallel-compilation` | `-C parallel-compilation=no` |
| `-g` | `-D debug-info` |
| `--disable-address-map` | `-D address-map=no` |
| `--disable-logging` | `-D logging=no` |
| `--log-to-files` | `-D log-to-files` |
| `--coredump-on-trap <PATH>` | `-D coredump=..` |
| `--wasm-features all` | `-W all-proposals` |
| `--wasm-features -all` | `-W all-proposals=n` |
| `--wasm-features bulk-memory` | `-W bulk-memory` |
| `--wasm-features multi-memory` | `-W multi-memory` |
| `--wasm-features multi-value` | `-W multi-value` |
| `--wasm-features reference-types` | `-W reference-types` |
| `--wasm-features simd` | `-W simd` |
| `--wasm-features tail-call` | `-W tail-call` |
| `--wasm-features threads` | `-W threads` |
| `--wasm-features memory64` | `-W memory64` |
| `--wasm-features copmonent-model` | `-W component-model` |
| `--wasm-features function-references` | `-W function-references` |
| `--relaxed-simd-deterministic` | `-W relaxed-simd-deterministic` |
| `--enable-cranelift-nan-canonicalization` | `-W nan-canonicalization` |
| `--fuel <N>` | `-W fuel=N` |
| `--epoch-interruption` | `-W epoch-interruption` |
| `--allow-unknown-exports` | `-W unknown-exports-allow` |
| `--trap-unknown-imports` | `-W unknown-imports-trap` |
| `--default-values-unknown-imports` | `-W unknown-imports-default` |
| `--max-instances <MAX_INSTANCES>` | `-W max-instances=N` |
| `--max-memories <MAX_MEMORIES>` | `-W max-memories=N` |
| `--max-memory-size <BYTES>` | `-W max-memory-size=N` |
| `--max-table-elements <MAX_TABLE_ELEMENTS>` | `-W max-table-elements=N` |
| `--max-tables <MAX_TABLES>` | `-W max-tables=N` |
| `--max-wasm-stack <MAX_WASM_STACK>` | `-W max-wasm-stack=N` |
| `--trap-on-grow-failure` | `-W trap-on-grow-failure` |
| `--wasm-timeout <TIME>` | `-W timeout=N` |
| `--wmemcheck` | `-W wmemcheck` |
| `--wasi-modules default` | removed |
| `--wasi-modules -default` | removed |
| `--wasi-modules wasi-common` | `-S common` |
| `--wasi-modules -wasi-common` | `-S common=n` |
| `--wasi-modules experimental-wasi-nn` | `-S nn` |
| `--wasi-modules experimental-wasi-threads` | `-S threads` |
| `--wasi-modules experimental-wasi-http` | `-S http` |
| `--listenfd` | `-S listenfd` |
| `--tcplisten <SOCKET ADDRESS>` | `-S tcplisten=...` |
| `--wasi-nn-graph <FORMAT::HOST>` | `-S nn-graph=FORMAT::HOST` |
| `--preview2` | `-S preview2` |
| `--dir <DIRECTORY>` | `--dir ...` |
| `--mapdir <GUEST_DIR::HOST_DIR>` | `--dir a::b` |
* Be more descriptive with help text
* Document `=val` is optional for `-Ccranelift-xxx`
* Fix compile after rebase
* Fix rebase of `--inherit-network`
* Fix wasi-http test
* Fix compile without pooling allocator support
* Update some flags in docs
* Fix bench-api build
* Update flags for gdb/lldb tests
* Fixup optimization flags
prtest:full
* Remove tutorial/wasm-writing documentation
This commit removes the tutorial and "Writing WebAssembly" documentation
sections from Wasmtime's documentation. These sections are quite dated
at this point (they still recommend `cargo wasi`!) and haven't been
updated much since their inception, especially in the arena of
components. Today it seems best to leave this sort of documentation to
[other resources] which are more tailored towards documentation of
writing wasm.
[other resources]: https://component-model.bytecodealliance.org/
* Remove markdown example from docs
Like the previous commit this is quite dated and recommends
effectively-deprecated tooling and doesn't take into account components.
* Update our intro docs a bit
* Link security blog post from docs
* Fold docs of wasm proposals into tier docs
This was already a bit duplicated so consolidate into one location.
Additionally add some proposals that weren't previously documented and
move some around based on their implementation status.
* Document unsupported features
In an effort to head off questions about platform support I figure it
might be a good idea to start documenting what's not supported at this
time. This is intended to mirror the current state, not future, of
Wasmtime. In other words this should answer the question of "Does
Wasmtime support X?" as opposed to "Does Wasmtime want to support X?"
since we want to eventually support all of these features in the limit.
* Fold WASI docs into tier docs
Similar to the previous commit but for WASI proposals.
While this is not at all WASM-specific, it is somewhat rare that
LLDB is used for native debugging on Windows, so the cause of
the slowdown on the order of 50x may not be immediately obvious.
* Update Rust in CI to 1.72.0
* Update CI, tooling, and docs for MSRV
This commit codifies an MSRV policy for Wasmtime at "stable minus two"
meaning that the latest three releases of Rust will be supported. This
is enforced on CI with a full test suite job running on Linux x86_64
with the minimum supported Rust version. The full test suite will use
the latest stable version. A downside of this approach is that new
changes may break MSRV support on non-Linux or non-x86_64 platforms and
we won't know about it, but that's deemed a minor enough risk at this
time.
A minor fix is applied to Wasmtime's `Cargo.toml` to support Rust 1.70.0
instead of requiring Rust 1.71.0
* Fix installation of rust
* Scrape MSRV from Cargo.toml
* Cranelift is the same as Wasmtime's MSRV now, more words too
* Fix a typo
* wmemcheck: update docs.
This PR expands the documentation for the Wasm memchecker (`wmemcheck`)
feature significantly, and also links it from the top-level
documentation hierarchy.
* Add syntax/language annotations to quotation sections to keep mdbook happy.
* Docs: Remove unneeded command in WASI-tutorial.md
The `cat /tmp/somewhere.txt` command in the example using --dir=$PWD is not needed. The error message should be after the first command anyway since it should be the one creating the message.
It looks like a copy/paste error since the previous example showed the same `cat` command a successful copy.
* Docs: Update error messages in WASI-tutorial.md.
The error messages appear to have changed since this document was originally written.
* Remove the implementation of wasi-crypto
This commit is a follow-up to the discussion on #6732. This removes
Wasmtime's implementation of the wasi-crypto proposal from in-tree along
with its various support in CI, configuration, etc. See the discussion
on #6732 for the full information but at a high level the main reasons
for removing the implementation at this time are:
* There is not currently an active maintainer of the Wasmtime
integration here for wasi-crypto.
* There are known issues with the code quality of the implementation
such as transmutes of guest-owned memory to `&'static mut [u8]` and
known unsafety in dependencies.
* The size and breadth of the dependency tree brings maintenance burden
and overhead to managing Wasmtime's dependency tree.
As mentioned on the issue this commit does not mean that Wasmtime
doesn't want to implement the wasi-crypto proposal. Instead the "tier 3"
status of wasi-crypto needs to be re-attained to be included back
in-tree, which would mean resolving the above issues.
Note that this commit is intentionally just after the 13.0.0 branch
point which means that this is slated for Wasmtime 14 to be released on
September 20.
* Remove some cfgs
* Remove wasi-crypto CI
this is causing a link error because pulldown_cmark is available both in
the rust_wasi_markdown_parser deps directory and, now, in the root of
the project as well.
Overall, I'm just trying to make these bits of documentation reflect our
process as it stands today. There are some specific changes I want to
draw attention to though.
Asking new contributors to pick a reviewer is a waste of time for two
reasons: Only people with write access to the repository are allowed to
pick reviewers, and new contributors have no idea who would be a good
reviewer for their PR anyway. So I'm deleting all mention of that. We
now auto-assign reviewers instead.
By the time someone is opening a PR, asking them to open an issue just
makes extra work for everyone. They've already picked an approach
without discussing it; we might as well look at what they did. We may
then have to ask them to take a different approach, but at that point,
asking them to open an issue won't save them any effort.
I removed mention of tests from the pull request template. There are
many things we'd like to see in a PR, and we may have to ask for them
during review if the contributor doesn't follow our development process
documentation. But I think the only crucial information for starting a
review is the two questions I'm leaving in the template: why do you want
this, and where can I find more context?
The code of conduct link still had the branch name as `master`, which is
a hint at how long it's been since anyone reviewed it.
* Add support for generating perf maps for simple perf profiling
* add missing enum entry in C code
* bugfix: use hexa when printing the code region's length too (thanks bjorn3!)
* sanitize file name + use bufwriter
* introduce --profile CLI flag for wasmtime
* Update doc and doc comments for new --profile option
* remove redundant FromStr import
* Apply review feedback: make_line receives a Write impl, report errors
* fix tests?
* better docs
* doc: add a page listing supported proposals
This adds a table showing Wasmtime's support for various WASI proposals,
much like the one available for WebAssembly proposals. This change is
related to [#2423], which provides guidelines for implementing WASI
proposals but was never merged.
[#2423]: https://github.com/bytecodealliance/wasmtime/pull/2423
* review: remove phase-gating sentence
This change adds a basic coredump generation after a WebAssembly trap
was entered. The coredump includes rudimentary stack / process debugging
information.
A new CLI argument is added to enable coredump generation:
```
wasmtime --coredump-on-trap=/path/to/coredump/file module.wasm
```
See ./docs/examples-coredump.md for a working example.
Refs https://github.com/bytecodealliance/wasmtime/issues/5732
At some point what is now `funcref` was called `anyfunc` and the spec changed,
but we didn't update our internal names. This does that.
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
These references are really, really old and are no longer applicable. In
general the `wasm-*.md` documentation needs a lot of updates but this
applies at least a small band-aid to remove the `#[wasm_bindgen]`
references which are likely more harmful than helpful.
* Remove explicit `S` type parameters
This commit removes the explicit `S` type parameter on `Func::typed` and
`Instance::get_typed_func`. Historical versions of Rust required that
this be a type parameter but recent rustcs support a mixture of explicit
type parameters and `impl Trait`. This removes, at callsites, a
superfluous `, _` argument which otherwise never needs specification.
* Fix mdbook examples
* Add definitions of tiers-of-support for Wasmtime
This commit adds documentation of a Tiers-based system for classifying
how supported a component is within Wasmtime. This was somewhat
pioneered in the [Wasmtime 1.0 RFC][rfc] but the documentation here is
expanded to include more than just API stability but additionally other
components. Inspiration for this is drawn from Rust's definition of
[support tiers][rust] as well.
The motivation for this is to help clarify what exactly it means to live
at each tier and what is expected. For example one thing this document
clarifies is the requirements necessary for landing new major changes in
Wasmtime at all. Additionally this helps clarify what it means to have
the highest level of support vs "otherwise well supported".
[rfc]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-one-dot-oh.md#tier-1---api-stable-production-quality
[rust]: https://doc.rust-lang.org/rustc/target-tier-policy.html
* Review comments
* Review comments
This PR removes all minutes and agendas in `meetings/`. These were
previously hosted in this repository, but we found that it makes things
somewhat more complex with respect to CI configuration and merge
permissions to have both small, CI-less changes to the text in
`meetings/` as well as changes to everything else in one repository.
The minutes and agendas have been split out into the repository at
https://github.com/bytecodealliance/meetings/, with all history
preserved. Future agenda additions and minutes contributions should go
there as PRs.
Finally, this PR adds a small note to our "Contributing" doc to note the
existence of the meetings and invite folks to ask to join if interested.
* Update wasm proposal support docs
Rename `--enable` flags to simply names and additionally replace module
linking with the component model.
* Fix a typo
* Improve the `wasmtime` crate's README
This commit is me finally getting back to #2688 and improving the README
of the `wasmtime` crate. Currently we have a [pretty drab README][drab]
that doesn't really convey what we want about Wasmtime.
While I was doing this I opted to update the feature list of Wasmtime as
well in the main README (which is mirrored into the crate readme),
namely adding a bullet point for "secure" which I felt was missing
relative to how we think about Wasmtime.
Naturally there's a lot of ways to paint this shed, so feedback is of
course welcome on this! (I'm not the best writer myself)
[drab]: https://crates.io/crates/wasmtime/0.37.0
* Expand the "Fast" bullet a bit more
* Reference the book from the wasmtime crate
* Update more security docs
Also merge the sandboxing security page with the main security page to
avoid the empty security page.
* Upgrade all crates to the Rust 2021 edition
I've personally started using the new format strings for things like
`panic!("some message {foo}")` or similar and have been upgrading crates
on a case-by-case basis, but I think it probably makes more sense to go
ahead and blanket upgrade everything so 2021 features are always
available.
* Fix compile of the C API
* Fix a warning
* Fix another warning
* Bump to 0.36.0
* Add a two-week delay to Wasmtime's release process
This commit is a proposal to update Wasmtime's release process with a
two-week delay from branching a release until it's actually officially
released. We've had two issues lately that came up which led to this proposal:
* In #3915 it was realized that changes just before the 0.35.0 release
weren't enough for an embedding use case, but the PR didn't meet the
expectations for a full patch release.
* At Fastly we were about to start rolling out a new version of Wasmtime
when over the weekend the fuzz bug #3951 was found. This led to the
desire internally to have a "must have been fuzzed for this long"
period of time for Wasmtime changes which we felt were better
reflected in the release process itself rather than something about
Fastly's own integration with Wasmtime.
This commit updates the automation for releases to unconditionally
create a `release-X.Y.Z` branch on the 5th of every month. The actual
release from this branch is then performed on the 20th of every month,
roughly two weeks later. This should provide a period of time to ensure
that all changes in a release are fuzzed for at least two weeks and
avoid any further surprises. This should also help with any last-minute
changes made just before a release if they need tweaking since
backporting to a not-yet-released branch is much easier.
Overall there are some new properties about Wasmtime with this proposal
as well:
* The `main` branch will always have a section in `RELEASES.md` which is
listed as "Unreleased" for us to fill out.
* The `main` branch will always be a version ahead of the latest
release. For example it will be bump pre-emptively as part of the
release process on the 5th where if `release-2.0.0` was created then
the `main` branch will have 3.0.0 Wasmtime.
* Dates for major versions are automatically updated in the
`RELEASES.md` notes.
The associated documentation for our release process is updated and the
various scripts should all be updated now as well with this commit.
* Add notes on a security patch
* Clarify security fixes shouldn't be previewed early on CI
Nick Fitzgerald
Alex Crichton
SingleAccretion
Chris Fallin
ssunkin-fastly
Jia Tan
Tom Stuart
Marco Concetto Rudilosso
Andrew Brown
JairusSW
Pat Hickey
Jamey Sharp
Max Große
Benjamin Bouvier
Tristan de Cacqueray
Sven Sauleau
Konstantin Shabanov
Alexander Günsche
Jimmy Bourassa
Dan King
Vasili Novikov
Bryant Luk
Daniel Marin
Frank Yang
Jeffrey Charles
Piotr Sikora
Kk Shinkai