|
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0 |
|
| #
133a0ef4 |
| 13-Mar-2026 |
Chris Fallin <[email protected]> |
Debugging: add the debug-main world. (#12756)
* Debugging: add the debug-main world.
This PR "draws the rest of the owl" for the debug-main world (bytecodealliance/rfcs#45). This includes a WIT wor
Debugging: add the debug-main world. (#12756)
* Debugging: add the debug-main world.
This PR "draws the rest of the owl" for the debug-main world (bytecodealliance/rfcs#45). This includes a WIT world that hosts debug components that have access to "host debug powers" via a debugging API, and the ability to load such a debug-component and give it control of the main program as a debuggee when using `wasmtime run`.
The WIT is namespaced to `bytecodealliance:wasmtime` and is slightly aspirational in places: for example, the host does not yet implement injection of early return values or exception-throws. I intend to fill out a series of TODO issues once this all lands to track followup ("post-MVP") work.
This PR does not include any debug components. I separately have a gdbstub component, with which I tested and co-developed this host-side implementation. My plan is to land it in a followup PR as a component that will be embedded in/shipped with the Wasmtime CLI and available under an easy-to-use CLI option. Once we have that gdbstub component, we can also implement end-to-end integration tests that boot up LLDB and run through an expected interaction. (Separately, those integration tests will require a release of wasi-sdk to ship an LLDB binary that we can use.) As such, there are no real tests in this PR: interesting behaviors only really occur with a full end-to-end flow.
The integration with the CLI is a little awkward (we internally build another `wasmtime run` command that invokes the debug component, and tie it together with the debuggee via a special `invoke_debugger` API; this seemed less bad than reworking all of the WASI setup to be more reusable). Happy to take more ideas here.
* Review feedback.
* Review feedback.
* Review feedback: update vendor-wit.sh.
* Review feedback: -Ddebugger-arg= -> -Darg=.
* Review feedback.
* Review feedback.
* Review feedback: factor host.rs into several submodules.
* Review feedback: rename Debugger to Debuggee on host side.
* Review feedback: split inherit_stdin_stdout, and add corresponding options for the debug component.
* Review feedback.
* Review feedback.
* Add simple debug-component tests.
* Add wasm32-wasip2 target in a few places in CI
* Cargo vets for wstd dependency.
* Add wasm32-wasip2 in more places
* fix debug-component test dependence on componentization byte offsets
* Review feedback.
* Fix cancel-safety of EventFuture.
* Fix: Interrupted events should only occur after interrupt(), not on every epoch yield.
* Review feedback.
* Review feedback: strip down WASI imports in debugger world.
* fold debugger test component back into wasip1 + adapter test artifact compilation flow
show more ...
|
|
Revision tags: v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1 |
|
| #
b11f8675 |
| 07-Jan-2026 |
Nick Fitzgerald <[email protected]> |
Migrate CLI flags to `wasmtime::error` (#12260)
|
|
Revision tags: v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1 |
|
| #
557cc2d6 |
| 10-Oct-2025 |
Alex Crichton <[email protected]> |
Another batch of dependency updates (#11832)
* Another batch of dependency updates
Bringing some deps in `Cargo.toml` up-to-date with their latest versions along the same lines as #11820 to avoid d
Another batch of dependency updates (#11832)
* Another batch of dependency updates
Bringing some deps in `Cargo.toml` up-to-date with their latest versions along the same lines as #11820 to avoid deps getting too stale/old.
Code-wise this updates `anyhow` which enables preexisting Clippy warnings to check more code, so those warnings are fixed here as well.
prtest:full
* Run rustfmt
show more ...
|
|
Revision tags: v37.0.2, v37.0.1, v37.0.0, v36.0.2 |
|
| #
73de2ee9 |
| 25-Aug-2025 |
Chris Fallin <[email protected]> |
Pull in new regalloc2 with fastalloc fixes for exceptions, and re-enable and add to testing. (#11533)
* Revert "Cranelift/Wasmtime: disable fastalloc (single-pass) allocator for now. (#10554)"
This
Pull in new regalloc2 with fastalloc fixes for exceptions, and re-enable and add to testing. (#11533)
* Revert "Cranelift/Wasmtime: disable fastalloc (single-pass) allocator for now. (#10554)"
This reverts commit d52e23b09191185996792b8ef18e5fca2865ca43.
* Upgrade to regalloc2 0.13.1.
Pulls in bytecodealliance/regalloc2#233 to update fastalloc to support the looser constraints needed by exception-related changes.
* cargo-vet update.
show more ...
|
|
Revision tags: v36.0.1, v36.0.0 |
|
| #
698028ce |
| 14-Aug-2025 |
Alex Crichton <[email protected]> |
Add a configuration knob for `PAGEMAP_SCAN` (#11433)
* Add a configuration knob for `PAGEMAP_SCAN`
This commit adds `PoolingAlloationConfig::pagemap_scan` and additionally adds `-Opooling-pagemap-s
Add a configuration knob for `PAGEMAP_SCAN` (#11433)
* Add a configuration knob for `PAGEMAP_SCAN`
This commit adds `PoolingAlloationConfig::pagemap_scan` and additionally adds `-Opooling-pagemap-scan` to configure on the CLI. This is the same tri-state configuration option as `MpkEnable` so that enum was renamed to just `Enabled` and repurposed for both options.
This then additionally turns the option off-by-default instead of the previous on-by-default-if-able-to to enable more slowly rolling out this feature.
* Fix broken test
show more ...
|
| #
3ecb338e |
| 29-Jul-2025 |
Nick Fitzgerald <[email protected]> |
Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)
* Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation
This commit plumbs together two pieces o
Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)
* Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation
This commit plumbs together two pieces of recently-added infrastructure:
1. function inlining in Cranelift, and 2. the parallel bottom-up inlining scheduler in Wasmtime.
Sprinkle some very simple inlining heuristics on top, and this gives us function inlining in Wasm compilation.
The default Wasmtime configuration does not enable inlining, and when we do enable it, we only enable it for cross-component calls by default (since presumably the toolchain that produced a particular core Wasm module, like LLVM, already performed any inlining that was beneficial within that module, but that toolchain couldn't know how that Wasm module would be getting linked together with other modules via component composition, and so it could not have done any cross-component inlining). For what it is worth, there is a config knob to enable intra-module function inlining, but this is primarily for use by our fuzzers, so that they can easily excercise and explore this new inlining functionality.
All this plumbing required some changes to the `wasmtime_environ::Compiler` trait, since Winch cannot do inlining but Cranelift can. This is mostly encapsulated in the new `wasmtime_environ::InliningCompiler` trait, for the most part. Additionally, we take care not to construct the call graph, or any other data structures required only by the inliner and not regular compilation, both when using Winch and when using Cranelift with inlining disabled.
Finally, we add a `disas` test to verify that we successfully inline a series of calls from a function in one component, to a cross-component adapter function, to a function in another component. Most test coverage is expected to come from our fuzzing, however.
* Fix dead code warning when not `cfg(feature = "component-model")`
* fix winch trampoline compilation
* Move CLI options to codegen
* Move parameters into struct
* Use an index set for call-graph construction
* Smuggle inlining heuristic options through cranelift flags
* Remove old CLI flags
* set tunables before settings
* Only configure inlining options for cranelift in fuzzing
show more ...
|
|
Revision tags: v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0 |
|
| #
90ac295e |
| 19-May-2025 |
Alex Crichton <[email protected]> |
Update Wasmtime to the 2024 Rust Edition (#10806)
* Update Wasmtime to the 2024 Rust Edition
Now that our MSRV supports the 2024 edition it's possible to make this switch. This commit moves Wasmtim
Update Wasmtime to the 2024 Rust Edition (#10806)
* Update Wasmtime to the 2024 Rust Edition
Now that our MSRV supports the 2024 edition it's possible to make this switch. This commit moves Wasmtime to the 2024 Edition to keep up-to-date with Rust idioms and access many of the edition features exclusive to the 2024 edition.
prtest:full
* Reformat with the 2024 edition
show more ...
|
|
Revision tags: v32.0.0 |
|
| #
d52e23b0 |
| 09-Apr-2025 |
Chris Fallin <[email protected]> |
Cranelift/Wasmtime: disable fastalloc (single-pass) allocator for now. (#10554)
Unfortunately, as discovered by a recent fuzzbug [1], the single-pass register allocator is not compatible with the ap
Cranelift/Wasmtime: disable fastalloc (single-pass) allocator for now. (#10554)
Unfortunately, as discovered by a recent fuzzbug [1], the single-pass register allocator is not compatible with the approach to callsite defs that exception-handling support has forced us to take. In particular, we needed to move all call return-value defs onto the call instruction itself, so calls could be terminators; this unbounded number of defs is made to be a solvable allocation problem by using `any` constraints, which allow allocation directly into spillslots; but fastalloc appears to error out if it runs out of registers, regardless of this constraint.
Long-term, we should fix this, but unfortunately I don't have cycles to dive into fastalloc's internals at the moment, and it's (I think) a tier-3 feature. As such, this PR disables its use for now. I've filed a tracking issue in RA2 [2], and referenced this in the Cranelift configuration option docs at least.
To keep from shifting all fuzzbugs / fuzzing corpii by altering the `arbitrary` interpretation, I opted to keep the enum the same in the fuzzing crate, and remap `SinglePass` to `Backtracking` there. I'm happy to take the other approach and remove the option (thus invalidating all fuzzbugs) if we'd prefer that instead.
[1]: https://oss-fuzz.com/testcase-detail/5433312476987392 [2]: https://github.com/bytecodealliance/regalloc2/issues/217
show more ...
|
|
Revision tags: v31.0.0 |
|
| #
bda83128 |
| 12-Mar-2025 |
Alex Crichton <[email protected]> |
Remove humantime crate dependency (#10379)
Turns out this has been unmaintained for quite some time now. It additionally is only a fringe benefit so hand-write a few parsers to replace it.
Closes #
Remove humantime crate dependency (#10379)
Turns out this has been unmaintained for quite some time now. It additionally is only a fringe benefit so hand-write a few parsers to replace it.
Closes #10378
show more ...
|
|
Revision tags: v30.0.2, v30.0.1, v30.0.0 |
|
| #
2a5c141c |
| 27-Jan-2025 |
Ludvig Liljenberg <[email protected]> |
Create wasmtime::Config from toml (#9811)
* Create wasmtime::Config from toml, add --config CLI flag
* Add cli tests
|
| #
ba4e22bc |
| 27-Jan-2025 |
Alex Crichton <[email protected]> |
Make it easier to reuse fuzzing configuration on the CLI (#10123)
* Make it easier to reuse fuzzing configuration on the CLI
During fuzzing we emit a debug log of configured options to assist with
Make it easier to reuse fuzzing configuration on the CLI (#10123)
* Make it easier to reuse fuzzing configuration on the CLI
During fuzzing we emit a debug log of configured options to assist with reproducing fuzz test cases outside of the fuzzing harness. Mapping options the fuzzer is using though to CLI flags, for example, is a bit of an art though and not obvious. Just today we've got a fuzz bug and I couldn't figure out how to reproduce on the CLI and it turns out the issue was that I was forgetting a flag that was being configured in response to another flag. I got a bit fed up with constantly trying to map one to the other, so I've decided to fix things.
This commit adds a `Display for CommonOptions` implementation to the `wasmtime-cli-flags` crate. This is built on the same macro-construction infrastructure of all our flags making it a relatively low one-time-cost to implement this. Each option value now implements not only parsing but printing as well.
Next the `wasmtime-fuzzing` crate was updated to create a `CommonOptions` first which is then in turn used to create a `wasmtime::Config`. This provides a layer to insert a log statement with to emit all configuration options in a form that can be easily copy/pasted to the CLI to reproduce.
Overall after doing this I was able to quickly reproduce the bug in question (yay!). The CLI flag logging is pretty verbose right now since the fuzzing infrastructure sets many settings redundantly to their defaults, but reducing flags to a minimum is expected to be relatively easy compared to otherwise trying to extract the options.
* Fix build and dependencies from wasmtime-fuzzing
* Always provide `wasmtime::MpkEnabled`
It's an otherwise very small `enum` which makes it easier to conditionally compile `wasmtime-cli-flags`
* Frob some crate features some more
* Fix specification of `wasmtime_linkopt_force_jump_veneer` option
show more ...
|
|
Revision tags: v29.0.1, v29.0.0, v28.0.1, v28.0.0 |
|
| #
45b60bd6 |
| 02-Dec-2024 |
Alex Crichton <[email protected]> |
Start using `#[expect]` instead of `#[allow]` (#9696)
* Start using `#[expect]` instead of `#[allow]`
In Rust 1.81, our new MSRV, a new feature was added to Rust to use `#[expect]` to control lint
Start using `#[expect]` instead of `#[allow]` (#9696)
* Start using `#[expect]` instead of `#[allow]`
In Rust 1.81, our new MSRV, a new feature was added to Rust to use `#[expect]` to control lint levels. This new lint annotation will silence a lint but will itself cause a lint if it doesn't actually silence anything. This is quite useful to ensure that annotations don't get stale over time.
Another feature is the ability to use a `reason` directive on the attribute with a string explaining why the attribute is there. This string is then rendered in compiler messages if a warning or error happens.
This commit migrates applies a few changes across the workspace:
* Some `#[allow]` are changed to `#[expect]` with a `reason`. * Some `#[allow]` have a `reason` added if the lint conditionally fires (mostly related to macros). * Some `#[allow]` are removed since the lint doesn't actually fire. * The workspace configures `clippy::allow_attributes_without_reason = 'warn'` as a "ratchet" to prevent future regressions. * Many crates are annotated to allow `allow_attributes_without_reason` during this transitionary period.
The end-state is that all crates should use `#[expect(..., reason = "...")]` for any lint that unconditionally fires but is expected. The `#[allow(..., reason = "...")]` lint should be used for conditionally firing lints, primarily in macro-related code. The `allow_attributes_without_reason = 'warn'` level is intended to be permanent but the transitionary `#[expect(clippy::allow_attributes_without_reason)]` crate annotations to go away over time.
* Fix adapter build
prtest:full
* Fix one-core build of icache coherence
* Use `allow` for missing_docs
Work around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn't fixed for our MSRV at this time.
* More MSRV compat
show more ...
|
|
Revision tags: v27.0.0 |
|
| #
1e3e5fc1 |
| 15-Nov-2024 |
Chris Fallin <[email protected]> |
Cranelift: add option to use new single-pass register allocator. (#9611)
* Cranelift: add option to use new single-pass register allocator.
In bytecodealliance/regalloc2#181, @d-sonuga added a fast
Cranelift: add option to use new single-pass register allocator. (#9611)
* Cranelift: add option to use new single-pass register allocator.
In bytecodealliance/regalloc2#181, @d-sonuga added a fast single-pass algorithm option to regalloc2, in addition to its existing backtracking allocator. This produces code much more quickly, at the expense of code quality. Sometimes this tradeoff is desirable (e.g. when performing a debug build in a fast-iteration development situation, or in an initial JIT tier).
This PR adds a Cranelift option to select the RA2 algorithm, plumbs it through to a Wasmtime option, and adds the option to Wasmtime fuzzing as well.
An initial compile-time measurement in Wasmtime: `spidermonkey.wasm` builds in 1.383s with backtracking (existing algorithm), and 1.065s with single-pass. The resulting binary runs a simple Fibonacci benchmark in 2.060s with backtracking vs. 3.455s with single-pass.
Hence, the single-pass algorithm yields a 23% compile-time reduction, at the cost of a 67% runtime increase.
* cargo-vet audit for allocator-api2 0.2.18 -> 0.2.20.
show more ...
|
|
Revision tags: v26.0.1, v25.0.3, v24.0.2 |
|
| #
83bf774d |
| 31-Oct-2024 |
Nick Fitzgerald <[email protected]> |
Add the "null" garbage collector (#9484)
* Add the "null" garbage collector
The null collector does not actually collect any garbage, it simply bump-allocates until the heap is exhausted, at which
Add the "null" garbage collector (#9484)
* Add the "null" garbage collector
The null collector does not actually collect any garbage, it simply bump-allocates until the heap is exhausted, at which point further allocation attempts will fail. It does not require any GC barriers.
Users can configure which collector to use via the `wasmtime::Config::collector` method or the `-C collector=drc|null` CLI flag. The `wasmtime::Collector` enumeration, similar to the `wasmtime::Strategy` enumeration but for choosing a collector rather than a compiler, additionally has a table summarizing the properties and characteristics of our current set of collector implementations.
Finally, we also run `.wast` tests that exercise GC types under both the DRC and null collectors. I tried to avoid running tests that are not related to GC under both configurations just to avoid a combinatorial blow up.
* cargo fmt
* fix +gc -gc-null -gc-drc build
* Fix some warnings in various cargo feature combo builds
* Fix some more warnings in certain build configs
* Fix unit tests for null GC
* Fill in some placeholder comments that I forgot to write
* Fix issues where we ask for a GC store when we don't actually need one
Which was causing test failures, since we no longer return a GC store with a dummy heap.
* Add fuzzing config support for different collectors
* address review feedback
* fix cmake tests
* Fix test compilation after rebase
* Fix GC tests under MIRI
show more ...
|
|
Revision tags: v26.0.0, v21.0.2, v22.0.1, v23.0.3, v25.0.2, v24.0.1 |
|
| #
81f9efc0 |
| 30-Sep-2024 |
Victor Adossi <[email protected]> |
feat(cli): allow underscores for numeric options used in wasmtime (#9332)
This commit allows for underscores to be used in numeric arguments to the wasmtime CLI.
For example, a string like `1_200`
feat(cli): allow underscores for numeric options used in wasmtime (#9332)
This commit allows for underscores to be used in numeric arguments to the wasmtime CLI.
For example, a string like `1_200` will be interpreted as `1200`.
Signed-off-by: Victor Adossi <[email protected]>
show more ...
|
|
Revision tags: v25.0.1, v25.0.0, v24.0.0, v23.0.2 |
|
| #
12fc764d |
| 30-Jul-2024 |
Xinzhao Xu <[email protected]> |
Integrate wasi-keyvalue into wasmtime-cli (#9032)
* Integrate wasi-keyvalue into wasmtime-cli
* fix miri check
|
|
Revision tags: v23.0.1, v23.0.0 |
|
| #
4b842a05 |
| 19-Jul-2024 |
Xinzhao Xu <[email protected]> |
Integrate wasi-runtime-config into wasmtime-cli (#8970)
|
|
Revision tags: v22.0.0, v21.0.1, v21.0.0, v20.0.2, v20.0.1, v20.0.0, v17.0.3, v19.0.2, v18.0.4, v19.0.1, v19.0.0 |
|
| #
8c8725e5 |
| 14-Mar-2024 |
Alex Crichton <[email protected]> |
Migrate all existing cranelift-filetest-based wasm tests to `tests/disas/*.wat` (#8140)
* Support hex numbers in CLI arguments
This enables `-O static-memory-maximum-size=0x10`, for example. Previo
Migrate all existing cranelift-filetest-based wasm tests to `tests/disas/*.wat` (#8140)
* Support hex numbers in CLI arguments
This enables `-O static-memory-maximum-size=0x10`, for example. Previously this was a parse error.
* Discover `disas` tests in subdirectories
* Deny unknown fields when parsing test configs
Make sure we don't accidentally have other configuration. Useful when porting tests over.
* Update `make-load-store-tests.sh` to new syntax
Pass various flags and such.
* Move all `*.wat` tests from `cranelift/filetests` into `tests/disas`
* Migrate all load/store tests
* Migrate all other `*.wat` tests to `tests/disas`
* Use opt-level=0 with table instructions
show more ...
|
|
Revision tags: v18.0.3, v18.0.2, v17.0.2, v18.0.1, v18.0.0, v17.0.1, v17.0.0, v16.0.0, v15.0.1, v15.0.0, v14.0.4, v14.0.3 |
|
| #
519808fc |
| 28-Oct-2023 |
Alex Crichton <[email protected]> |
Add compatibility shims for Wasmtime 13 CLI (#7385)
* Add compatibility shims for Wasmtime 13 CLI
This commit introduces a compatibility shim for the Wasmtime 13 CLI and prior. The goal of this com
Add compatibility shims for Wasmtime 13 CLI (#7385)
* Add compatibility shims for Wasmtime 13 CLI
This commit introduces a compatibility shim for the Wasmtime 13 CLI and prior. The goal of this commit is to address concerns raised in #7336 and other locations as well. While the new CLI cannot be un-shipped at this point this PR attempts to ameliorate the situation somewhat through a few avenues:
* A complete copy of the old CLI parser is now included in `wasmtime` by default. * The `WASMTIME_NEW_CLI=0` environment variable can force usage of the old CLI parser for the `run` and `compile` commands. * The `WASMTIME_NEW_CLI=1` environment variable can force usage of the new CLI parser. * Otherwise both the old and the new CLI parser are executed. Depending on the result one is selected to be executed, possibly with a warning printed. * If both CLI parsers succeed but produce the same result, then no warning is emitted and execution continues as usual. * If both CLI parsers succeed but produce different results then a warning is emitted indicating this. The warning points to #7384 which has further examples of how to squash the warning. The warning also mentions the above env var to turn the warning off. In this situation the old semantics are used at this time instead of the new semantics. It's intended that eventually this will change in the future. * If the new CLI succeeds and the old CLI fails then the new semantics are executed without warning. * If the old CLI succeeds and the new CLI fails then a warning is issued and the old semantics are used. * If both the old and the new CLI fail to parse then the error message for the new CLI is emitted.
Note that this doesn't add up to a perfect transition. The hope is that most of the major cases of change at the very least have something printed. My plan is to land this on `main` and then backport it to the 14.0.0 branch as a 14.0.3 release.
* Wordsmith messages
* Update messages
* More wording updates
* Fix grammar
* More updates
show more ...
|
|
Revision tags: v14.0.2, v13.0.1, v14.0.1, v14.0.0, minimum-viable-wasi-proxy-serve, v13.0.0, v12.0.2, v11.0.2, v10.0.2 |
|
| #
8995750a |
| 11-Sep-2023 |
Alex Crichton <[email protected]> |
Redesign Wasmtime's CLI (#6925)
* 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
Redesign Wasmtime's CLI (#6925)
* 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
show more ...
|