Changes in compile.rs

94740588 - Migrate the Wasmtime CLI to `wasmtime::error` (#12295)

Fri, 09 Jan 2026 19:15:48 +0000

Migrate the Wasmtime CLI to `wasmtime::error` (#12295)* Migrate wasmtime-cli to `wasmtime::error`* migrate benches to `wasmtime::error` as well* Remove new usage of anyhow that snuck in List of files: /wasmtime-44.0.1/src/commands/compile.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/src/commands/compile.rs

c3aa6a53 - Change `allow(missing_docs)` to `expect(..)` (#10384)

Wed, 12 Mar 2025 18:58:45 +0000

Change `allow(missing_docs)` to `expect(..)` (#10384)This wasn't possible when `expect` was first introduced due to a changebeing required in upstream rust-lang/rust. That changerust-lang/rust#130025) has now rode enough trains to be in our MSRV, sowe can expect missing docs now instead of just allowing it. List of files: /wasmtime-44.0.1/src/commands/compile.rs

ed7eb500 - Require lint reasons in `wasmtime-cli` (#10175)

Mon, 03 Feb 2025 19:15:08 +0000

Require lint reasons in `wasmtime-cli` (#10175)Continuation of #9696 List of files: /wasmtime-44.0.1/src/commands/compile.rs

57cd5a9e - Start plumbing the ability to run Pulley in Wasmtime (#9646)

Thu, 21 Nov 2024 19:50:51 +0000

Start plumbing the ability to run Pulley in Wasmtime (#9646)* Start plumbing the ability to run Pulley in WasmtimeThis commit starts setting up some infrastructure to run Pulley modulesin Wasmtime, for example on the CLI. This doesn't actually work just yetdue to other missing pieces of integration but this is enough to get toa fault and/or other compiler errors at this time. The changes here are:* An `Engine` allows mismatching targets in the case of Pulley, but the pointer widths must match.* All subcommands of Wasmtime now support `--target`, e.g. `wasmtime run`, as previously only the host was allowed.* Fix compile of bench-api* Fix miri tests* Switch from `NativeEndian` to `Endianness`This switches parsing ELF from always using the native endianness toinstead using a runtime-defined value of endianness. This enablesbig-endian platforms such as s390x to load objects produced for pulley,a little-endian platform. List of files: /wasmtime-44.0.1/src/commands/compile.rs

be12a665 - Remove `PartialEq` implementations from CLI flags (#9628)

Wed, 20 Nov 2024 17:57:13 +0000

Remove `PartialEq` implementations from CLI flags (#9628)These are historical artifacts from when the pre-Wasmtime-13 CLI wassupported but they're no longer needed nowadays. List of files: /wasmtime-44.0.1/src/commands/compile.rs

b79a96a1 - Leverage Rust 1.79, 1.80 (#9498)

Tue, 22 Oct 2024 22:00:39 +0000

Leverage Rust 1.79, 1.80 (#9498)This commit is a follow-up to #9496 to leverage various APIs that theworkspace now has access to. For example most dependencies on the`once_cell` crate are now removed in favor of the types stabilized inthe standard library: `LazyLock` and `LazyCell`. One dependency remainsin the `wasmtime` crate due to the `get_or_try_init` not being stableyet.Some additional helper methods on raw pointer slices are also availablefor removing a few minor `unsafe` blocks. List of files: /wasmtime-44.0.1/src/commands/compile.rs

3f5c21bf - Add initial f16 and f128 support to the aarch64 backend (#9076)

Fri, 16 Aug 2024 17:34:13 +0000

Add initial f16 and f128 support to the aarch64 backend (#9076) List of files: /wasmtime-44.0.1/src/commands/compile.rs

f673cde3 - Refactor use of `CodeBuilder` on the CLI (#9125)

Wed, 14 Aug 2024 17:31:07 +0000

Refactor use of `CodeBuilder` on the CLI (#9125)* Refactor use of `CodeBuilder` on the CLIThis commit refactors `wasmtime run` and `wasmtime compile` tounconditionally use `CodeBuilder` internally. This will in theory helpout in the future if more debug-related options are added to`CodeBuilder` for example. This refactoring required some changes to`CodeBuilder` to be able to support a query about whether the internalbytes were a component or a module. The text format is now converted tobinary immediately when supplied rather than during the compilationphase. This in turn required some API changes to make the selection ofsupporting the text format a compile-time choice of method rather than aruntime value.* Fix compile* Fix no-cranelift build of CLI List of files: /wasmtime-44.0.1/src/commands/compile.rs

ccf8e40f - Support DWARF packages for `wasmtime compile` (#9110)

Tue, 13 Aug 2024 01:55:20 +0000

Support DWARF packages for `wasmtime compile` (#9110)Previously we didn't pass the path to the Wasm file, so we didn't find theassociated DWARF package. List of files: /wasmtime-44.0.1/src/commands/compile.rs

dc1d128a - Respect pooling allocation options in `wasmtime serve` (#8525)

Fri, 03 May 2024 19:47:22 +0000

Respect pooling allocation options in `wasmtime serve` (#8525)* Respect pooling allocation options in `wasmtime serve`This commit updates the processing of pooling allocator options in`wasmtime serve`. Previously the pooling allocator was enabled bydefault but the options to configure it weren't processed due to howthis default-enable was implemented. The option to enable it by defaultfor `wasmtime serve`, but only `wasmtime serve`, is now processeddifferently in a way that handles various otherpooling-allocator-related options.Closes #8504* Fix compile of bench api* Fix test build* Ignore newly added test as it's flaky List of files: /wasmtime-44.0.1/src/commands/compile.rs

0fa13013 - Add `GcRuntime` and `GcCompiler` traits; `i31ref` support (#8196)

Thu, 04 Apr 2024 00:24:50 +0000

Add `GcRuntime` and `GcCompiler` traits; `i31ref` support (#8196)\### The `GcRuntime` and `GcCompiler` TraitsThis commit factors out the details of the garbage collector away from the restof the runtime and the compiler. It does this by introducing two new traits,very similar to a subset of [those proposed in the Wasm GC RFC], although notall equivalent functionality has been added yet because Wasmtime doesn'tsupport, for example, GC structs yet:[those proposed in the Wasm GC RFC]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md#defining-the-pluggable-gc-interface1. The `GcRuntime` trait: This trait defines how to create new GC heaps, run collections within them, and execute the various GC barriers the collector requires. Rather than monomorphize all of Wasmtime on this trait, we use it as a dynamic trait object. This does imply some virtual call overhead and missing some inlining (and resulting post-inlining) optimization opportunities. However, it is *much* less disruptive to the existing embedder API, results in a cleaner embedder API anyways, and we don't believe that VM runtime/embedder code is on the hot path for working with the GC at this time anyways (that would be the actual Wasm code, which has inlined GC barriers and direct calls and all of that). In the future, once we have optimized enough of the GC that such code is ever hot, we have options we can investigate at that time to avoid these dynamic virtual calls, like only enabling one single collector at build time and then creating a static type alias like `type TheOneGcImpl = ...;` based on the compile time configuration, and using this type alias in the runtime rather than a dynamic trait object. The `GcRuntime` trait additionally defines a method to reset a GC heap, for use by the pooling allocator. This allows reuse of GC heaps across different stores. This integration is very rudimentary at the moment, and is missing all kinds of configuration knobs that we should have before deploying Wasm GC in production. This commit is large enough as it is already! Ideally, in the future, I'd like to make it so that GC heaps receive their memory region, rather than allocate/reserve it themselves, and let each slot in the pooling allocator's memory pool be *either* a linear memory or a GC heap. This would unask various capacity planning questions such as "what percent of memory capacity should we dedicate to linear memories vs GC heaps?". It also seems like basically all the same configuration knobs we have for linear memories apply equally to GC heaps (see also the "Indexed Heaps" section below).2. The `GcCompiler` trait: This trait defines how to emit CLIF that implements GC barriers for various operations on GC-managed references. The Rust code calls into this trait dynamically via a trait object, but since it is customizing the CLIF that is generated for Wasm code, the Wasm code itself is not making dynamic, indirect calls for GC barriers. The `GcCompiler` implementation can inline the parts of GC barrier that it believes should be inline, and leave out-of-line calls to rare slow paths.All that said, there is still only a single implementation of each of thesetraits: the existing deferred reference-counting (DRC) collector. So there is abunch of code motion in this commit as the DRC collector was further isolatedfrom the rest of the runtime and moved to its own submodule. That said, this wasnot *purely* code motion (see "Indexed Heaps" below) so it is worth not simplyskipping over the DRC collector's code in review.\### Indexed HeapsThis commit does bake in a couple assumptions that must be shared across allcollector implementations, such as a shared `VMGcHeader` that all objectsallocated within a GC heap must begin with, but the most notable andfar-reaching of these assumptions is that all collectors will use "indexedheaps".What we are calling indexed heaps are basically the three following invariants:1. All GC heaps will be a single contiguous region of memory, and all GC objects will be allocated within this region of memory. The collector may ask the system allocator for additional memory, e.g. to maintain its free lists, but GC objects themselves will never be allocated via `malloc`.2. A pointer to a GC-managed object (i.e. a `VMGcRef`) is a 32-bit offset into the GC heap's contiguous region of memory. We never hold raw pointers to GC objects (although, of course, we have to compute them and use them temporarily when actually accessing objects). This means that deref'ing GC pointers is equivalent to deref'ing linear memory pointers: we need to add a base and we also check that the GC pointer/index is within the bounds of the GC heap. Furthermore, compressing 64-bit pointers into 32 bits is a fairly common technique among high-performance GC implementations[^compressed-oops][^v8-ptr-compression] so we are in good company.3. Anything stored inside the GC heap is untrusted. Even each GC reference that is an element of an `(array (ref any))` is untrusted, and bounds checked on access. This means that, for example, we do not store the raw pointer to an `externref`'s host object inside the GC heap. Instead an `externref` now stores an ID that can be used to index into a side table in the store that holds the actual `Box` host object, and accessing that side table is always checked.[^compressed-oops]: See ["Compressed OOPs" in OpenJDK.](https://wiki.openjdk.org/display/HotSpot/CompressedOops)[^v8-ptr-compression]: See [V8's pointer compression](https://v8.dev/blog/pointer-compression).The good news with regards to all the bounds checking that this scheme impliesis that we can use all the same virtual memory tricks that linear memories useto omit explicit bounds checks. Additionally, (2) means that the sizes of GCobjects is that much smaller (and therefore that much more cache friendly)because they are only holding onto 32-bit, rather than 64-bit, references toother GC objects. (We can, in the future, support GC heaps up to 16GiB in sizewithout losing 32-bit GC pointers by taking advantage of `VMGcHeader` alignmentand storing aligned indices rather than byte indices, while still leaving thebottom bit available for tagging as an `i31ref` discriminant. Should we everneed to support even larger GC heap capacities, we could go to full 64-bitreferences, but we would need explicit bounds checks.)The biggest benefit of indexed heaps is that, because we are (explicitly orimplicitly) bounds checking GC heap accesses, and because we are not otherwisetrusting any data from inside the GC heap, we greatly reduce how badly thingscan go wrong in the face of collector bugs and GC heap corruption. We areessentially sandboxing the GC heap region, the same way that linear memory is asandbox. GC bugs could lead to the guest program accessing the wrong GC object,or getting garbage data from within the GC heap. But only garbage data fromwithin the GC heap, never outside it. The worse that could happen would be if wedecided not to zero out GC heaps between reuse across stores (which is a validtrade off to make, since zeroing a GC heap is a defense-in-depth techniquesimilar to zeroing a Wasm stack and not semantically visible in the absence ofGC bugs) and then a GC bug would allow the current Wasm guest to read old GCdata from the old Wasm guest that previously used this GC heap. But again, itcould never access host data.Taken altogether, this allows for collector implementations that are nearly freefrom `unsafe` code, and unsafety can otherwise be targeted and limited in scope,such as interactions with JIT code. Most importantly, we do not have to maintaincritical invariants across the whole system -- invariants which can't be nicelyencapsulated or abstracted -- to preserve memory safety. Such holisticinvariants that refuse encapsulation are otherwise generally a huge safetyproblem with GC implementations.\### `VMGcRef` is *NOT* `Clone` or `Copy` Anymore`VMGcRef` used to be `Clone` and `Copy`. It is not anymore. The motivation herewas to be sure that I was actually calling GC barriers at all the correctplaces. I couldn't be sure before. Now, you can still explicitly copy a raw GCreference without running GC barriers if you need to and understand why that'sokay (aka you are implementing the collector), but that is something you have toopt into explicitly by calling `unchecked_copy`. The default now is that youcan't just copy the reference, and instead call an explicit `clone` method (not*the* `Clone` trait, because we need to pass in the GC heap context to run theGC barriers) and it is hard to forget to do that accidentally. This resulted ina pretty big amount of churn, but I am wayyyyyy more confident that the correctGC barriers are called at the correct times now than I was before.\### `i31ref`I started this commit by trying to add `i31ref` support. And it grew into thewhole traits interface because I found that I needed to abstract GC barriersinto helpers anyways to avoid running them for `i31ref`s, so I figured that Imight as well add the whole traits interface. In comparison, `i31ref` support ismuch easier and smaller than that other part! But it was also difficult to pullapart from this commit, sorry about that!---------------------Overall, I know this is a very large commit. I am super happy to have somesynchronous meetings to walk through this all, give an overview of thearchitecture, answer questions directly, etc... to make review easier!prtest:full List of files: /wasmtime-44.0.1/src/commands/compile.rs

71951c9c - Enable compiling the Wasmtime CLI to Wasm (#7980)

Fri, 23 Feb 2024 00:13:33 +0000

Enable compiling the Wasmtime CLI to Wasm (#7980)* Enable compiling the Wasmtime CLI to WasmWhile not the most useful thing to do in the world it's kind of neat toplay around with. This builds on the previous work to exclude theruntime from the `wasmtime` crate so it's now possible to compile theWasmtime CLI's `compile` command, and only the `compile` command, towasm itself. This means you can run Wasmtime in Wasmtime!* Fix warning on wasm* Fix some feature combos List of files: /wasmtime-44.0.1/src/commands/compile.rs

f9f8a4df - Replace clap attributes with command and arg (#7658)

Fri, 08 Dec 2023 16:19:10 +0000

Replace clap attributes with command and arg (#7658) List of files: /wasmtime-44.0.1/src/commands/compile.rs

519808fc - Add compatibility shims for Wasmtime 13 CLI (#7385)

Sat, 28 Oct 2023 00:11:19 +0000

Add compatibility shims for Wasmtime 13 CLI (#7385)* Add compatibility shims for Wasmtime 13 CLIThis commit introduces a compatibility shim for the Wasmtime 13 CLI andprior. The goal of this commit is to address concerns raised in #7336and other locations as well. While the new CLI cannot be un-shipped atthis point this PR attempts to ameliorate the situation somewhat througha 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 thatmost of the major cases of change at the very least have somethingprinted. My plan is to land this on `main` and then backport it to the14.0.0 branch as a 14.0.3 release.* Wordsmith messages* Update messages* More wording updates* Fix grammar* More updates List of files: /wasmtime-44.0.1/src/commands/compile.rs

d86afc02 - Gate many CLI/Wasmtime features behind Cargo features (#7282)

Thu, 19 Oct 2023 18:01:35 +0000

Gate many CLI/Wasmtime features behind Cargo features (#7282)* Move `wasmtime explore` behind a Cargo featureEnable this Cargo feature by default, but enable building the CLIwithout the `explore` subcommand.* Move the `wast` subcommand behind a Cargo feature* Move support for `wat` behind a CLI featureThis was already conditional in crates such as `wasmtime` and this makesit an optional dependency of the CLI as well.* Move CLI cache support behind a Cargo featureAdditionally refactor `wasmtime-cli-flags` to not unconditionally pullin caching support by removing its `default` feature and appropriatelyenabling it from the CLI.* Move `rayon` behind an optional feature* Move `http-body-util` dependency behind `serve` feature* Add a Cargo feature for compiling out log statementsThis sets the static features of `log` and `tracing` to staticallyremove all log statements from the binary to cut down on binary size.* Move logging support behind a Cargo featureEnables statically removing logging support in addition to the previouscompiling out log statements themselves.* Move demangling support behind a Cargo feature* Enable building the CLI without craneliftCompile out the `compile` subcommand for example.* Gate all profiling support behind one feature flagThis commit moves vtune/jitdump support behind a single `profiling`feature flag that additionally includes the guest profiler dependenciesnow too.* Move support for core dumps behind a feature flag* Move addr2line behind a feature* Fix rebase* Document cargo features and a minimal build* Tidy up the source a bit* Rename compile-out-logging* Document disabling logging* Note the host architecture as well* Fix tests* Fix tests* Mention debuginfo stripping* Fix CI configuration for checking features* Fix book tests* Update lock file after rebase* Enable coredump feature by default List of files: /wasmtime-44.0.1/src/commands/compile.rs

8995750a - Redesign Wasmtime's CLI (#6925)

Mon, 11 Sep 2023 22:05:35 +0000

Redesign Wasmtime's CLI (#6925)* Redesign Wasmtime's CLIThis commit follows through on discussion from #6741 to redesign theflags that the `wasmtime` binary accepts on the CLI. Almost all flagshave been renamed/moved and will require callers to update. The mainmotivation 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 "optiongroups" 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 exampleEach option group can be explored by passing `help`, for example `-Ohelp`. This will print all options within the group along with theirhelp message. Additionally `-O help-long` can be passed to print thefull comment for each option if desired.Option groups can be specified multiple times on the command line, forexample `-Wrelaxed-simd -Wthreads`. They can also be combined togetherwith commas as `-Wrelaxed-simd,threads`. Configuration works as a "lastoption wins" so `-Ccache,cache=n` would end up with a compilationcache disabled.Boolean options can be specified as `-C foo` to enable `foo`, or theycan be specified with `-Cfoo=$val` with any of `y`, `n`, `yes`, `no`,`true`, or `false`. All other options require a `=foo` value to bepassed and the parsing depends on the type.This commit additionally applies a few small refactorings to the CLI aswell. For example the help text no longer prints information about wasmfeatures 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 insteadall flags are always supported. A runtime error is returned if supportfor a flag is not compiled in. Additionally the "experimental" name ofWASI proposals has been dropped in favor of just the name of theproposal, for example `--wasi nn` instead of `--wasi-modulesexperimental-wasi-nn`. This is intended to mirror how wasm proposalsdon't have "experimental" in the name and an opt-in is requiredregardless.A full listing of flags and how they have changed is:| old cli flag | new cli flag ||-----------------------------------------------|-------------------------------------------------|| `-O, --optimize` | removed || `--opt-level ` | `-O opt-level=N` || `--dynamic-memory-guard-size ` | `-O dynamic-memory-guard-size=...` || `--static-memory-forced` | `-O static-memory-forced` || `--static-memory-guard-size ` | `-O static-memory-guard-size=N` || `--static-memory-maximum-size ` | `-O static-memory-maximum-size=N` || `--dynamic-memory-reserved-for-growth ` | `-O dynamic-memory-reserved-for-growth=...` || `--pooling-allocator` | `-O pooling-allocator` || `--disable-memory-init-cow` | `-O memory-init-cow=no` || `--compiler ` | `-C compiler=..` || `--enable-cranelift-debug-verifier` | `-C cranelift-debug-verifier` || `--cranelift-enable ` | `-C cranelift-NAME` || `--cranelift-set ` | `-C cranelift-NAME=VALUE` || `--config ` | `-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 ` | `-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 ` | `-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 ` | `-W max-instances=N` || `--max-memories ` | `-W max-memories=N` || `--max-memory-size ` | `-W max-memory-size=N` || `--max-table-elements ` | `-W max-table-elements=N` || `--max-tables ` | `-W max-tables=N` || `--max-wasm-stack ` | `-W max-wasm-stack=N` || `--trap-on-grow-failure` | `-W trap-on-grow-failure` || `--wasm-timeout ` | `-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 ` | `-S tcplisten=...` || `--wasi-nn-graph ` | `-S nn-graph=FORMAT::HOST` || `--preview2` | `-S preview2` || `--dir ` | `--dir ...` || `--mapdir ` | `--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 flagsprtest:full List of files: /wasmtime-44.0.1/src/commands/compile.rs

367bdc8c - Refactor Wasmtime CLI to support components (#6836)

Sat, 19 Aug 2023 00:15:01 +0000

Refactor Wasmtime CLI to support components (#6836)This commit refactors the `wasmtime` CLI executable to be able tosupport not only compiling components but additionally executingcomponents. While I was doing this I've additionally added a new`--preview2` argument to enable using the new experimentalimplementation of preview1 based on preview2 type/structs. This isoff-by-default but is expected to become the default in the future.Some notable features of this change are:* The preview1-implemented-with-preview2 module now sports `add_to_linker_{async,sync}` to replace the previous `add_to_linker` which always did async.* Some trait bounds in the preview1-implemented-with-preview2 module are simplified.* Some minor changes were made to `wiggle`'s macros to support a "block on" that isn't the default wiggle dummy executor (as now we actually do need Tokio)* Many options related to core wasm `Linker` configuration, such as `--default-values-unknown-imports`, are not implemented for components at this time. When used with components these options return an error.* Construction of WASI contexts has been refactored to pass around fewer arguments to avoid threading through lots of values for both preview1 and preview2.* Reading the input to the Wasmtime CLI has been updated to read the input in the `run` subcommand before handing it off to the `wasmtime` crate's API to enable the CLI to use the contents of what's loaded to determine what to do next.* Our generic `./ci/run-tests.sh` script has been updated to pass the `--features component-model` flag to ensure that this CLI support is tested during the normal test suite.* The CLI support for `wasi-nn` supports components as well as core wasm modules. List of files: /wasmtime-44.0.1/src/commands/compile.rs

6d7bb360 - Dependency gardening for Wasmtime (#6731)

Sat, 15 Jul 2023 03:00:05 +0000

Dependency gardening for Wasmtime (#6731)* Remove deny.toml exception for wasm-coredump-builderThis isn't used any more so no need to continue to list this.* Update Wasmtime's pretty_env_logger dependencyThis removes a `deny.toml` exception for that crate, but `openvino-sys`still depends on `pretty_env_logger 0.4.0` so a new exception is addedfor that.* Update criterion and clap dependenciesThis commit started out by updating the `criterion` dependency to removean entry in `deny.toml`, but that ended up transitively requiring a`clap` dependency upgrade from 3.x to 4.x because `criterion` usespieces of clap 4.x. Most of this commit is then dedicated to updatingclap 3.x to 4.x which was relatively simple, mostly renaming attributeshere and there.* Update gimli-related dependenciesI originally wanted to remove the `indexmap` clause in `deny.toml` butenough dependencies haven't updated from 1.9 to 2.0 that it wasn'tpossible. In the meantime though this updates some various dependenciesto bring them to the latest and a few of them now use `indexmap` 2.0.* Update deps to remove `windows-sys 0.45.0`This involved updating tokio/mio and then providing new audits for newcrates. The tokio exemption was updated from its old version to the newversion and tokio remains un-audited.* Update `syn` to 2.x.xThis required a bit of rewriting for the component-macro related bitsbut otherwise was pretty straightforward. The `syn` 1.x.x track is stillpresent in the wasi-crypto tree at this time.I've additionally added some trusted audits for my own publications of`wasm-bindgen`* Update bitflags to 2.x.xThis updates Wasmtime's dependency on the `bitflags` crate to the 2.x.xtrack to keep it up-to-date.* Update the cap-std family of cratesThis bumps them all to the next major version to keep up with updates.I've additionally added trusted entries for publishes of cap-std cratesfrom Dan.There's still lingering references to rustix 0.37.x which will need toget weeded out over time.* Update memoffset dependency to latestAvoids having two versions in our crate graph.* Fix tests* Update try_from for wiggle flags* Fix build on AArch64 Linux* Enable `event` for rustix on Windows too List of files: /wasmtime-44.0.1/src/commands/compile.rs

c0bb341d - Run some tests in MIRI on CI (#6332)

Wed, 03 May 2023 21:02:33 +0000

Run some tests in MIRI on CI (#6332)* Run some tests in MIRI on CIThis commit is an implementation of getting at least chunks of Wasmtimeto run in MIRI on CI. The full test suite is not possible to run in MIRIbecause MIRI cannot run Cranelift-produced code at runtime (aka itdoesn't support JITs). Running MIRI, however, is still quite valuable ifwe can manage it because it would have trivially detectedGHSA-ch89-5g45-qwc7, our most recent security advisory. The goal of thisPR is to select a subset of the test suite to execute in CI under MIRIand boost our confidence in the copious amount of `unsafe` code inWasmtime's runtime.Under MIRI's default settings, which is to use the [StackedBorrows][stacked] model, much of the code in `Instance` and `VMContext`is considered invalid. Under the optional [Tree Borrows][tree] model,however, this same code is accepted. After some [extremely helpfuldiscussion][discuss] on the Rust Zulip my current conclusion is thatwhat we're doing is not fundamentally un-sound but we need to model itin a different way. This PR, however, uses the Tree Borrows model forMIRI to get something onto CI sooner rather than later, and I hope tofollow this up with something that passed Stacked Borrows. Additionallythat'll hopefully make this diff smaller and easier to digest.Given all that, the end result of this PR is to get 131 separate unittests executing on CI. These unit tests largely exercise the embeddingAPI where wasm function compilation is not involved. Some tests compilewasm functions but don't run them, but compiling wasm through Craneliftin MIRI is so slow that it doesn't seem worth it at this time. This doesmean that there's a pretty big hole in MIRI's test coverage, but that'sto be expected as we're a JIT compiler after all.To get tests working in MIRI this PR uses a number of strategies:* When platform-specific code is involved there's now `#[cfg(miri)]` for MIRI's version. For example there's a custom-built "mmap" just for MIRI now. Many of these are simple noops, some are `unimplemented!()` as they shouldn't be reached, and some are slightly nontrivial implementations such as mmaps and trap handling (for native-to-native function calls).* Many test modules are simply excluded via `#![cfg(not(miri))]` at the top of the file. This excludes the entire module's worth of tests from MIRI. Other modules have `#[cfg_attr(miri, ignore)]` annotations to ignore tests by default on MIRI. The latter form is used in modules where some tests work and some don't. This means that all future test additions will need to be effectively annotated whether they work in MIRI or not. My hope though is that there's enough precedent in the test suite of what to do to not cause too much burden.* A number of locations are fixed with respect to MIRI's analysis. For example `ComponentInstance`, the component equivalent of `wasmtime_runtime::Instance`, was actually left out from the fix for the CVE by accident. MIRI dutifully highlighted the issues here and I've fixed them locally. Some locations fixed for MIRI are changed to something that looks similar but is subtly different. For example retaining items in a `Store` is now done with a Wasmtime-specific `StoreBox` type. This is because, with MIRI's analyses, moving a `Box` invalidates all pointers derived from this `Box`. We don't want these semantics, so we effectively have a custom `Box` to suit our needs in this regard.* Some default configuration is different under MIRI. For example most linear memories are dynamic with no guards and no space reserved for growth. Settings such as parallel compilation are disabled. These are applied to make MIRI "work by default" in more places ideally. Some tests which perform N iterations of something perform fewer iterations on MIRI to not take quite so long.This PR is not intended to be a one-and-done-we-never-look-at-it-againkind of thing. Instead this is intended to lay the groundwork tocontinuously run MIRI in CI to catch any soundness issues. This feels,to me, overdue given the amount of `unsafe` code inside of Wasmtime. Myhope is that over time we can figure out how to run Wasm in MIRI butthat may take quite some time. Regardless this will be adding nontrivialmaintenance work to contributors to Wasmtime. MIRI will be run on CI formerges, MIRI will have test failures when everything else passes,MIRI's errors will need to be deciphered by those who have probablynever run MIRI before, things like that. Despite all this to me it seemsworth the cost at this time. Just getting this running caught twopossible soundness bugs in the component implementation that could havehad a real-world impact in the future![stacked]: https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md[tree]: https://perso.crans.org/vanille/treebor/[discuss]: https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Tree.20vs.20Stacked.20Borrows.20.26.20a.20debugging.20question* Update alignment comment List of files: /wasmtime-44.0.1/src/commands/compile.rs