History log of /wasmtime-44.0.1/src/bin/wasmtime.rs (Results 1 – 25 of 72)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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, 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
# 94740588 09-Jan-2026 Nick Fitzgerald <[email protected]>

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


Revision tags: v40.0.1, v40.0.0
# 4898322a 18-Dec-2025 Alex Crichton <[email protected]>

Update MSRV to 1.90.0 (#12167)

* Update MSRV to 1.90.0

Coupled with last week's release of 1.92.0.

prtest:full

* Fix some warnings

* Fix another warning


Revision tags: 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
# 18aff9aa 13-Oct-2025 Alex Crichton <[email protected]>

Integrate wizer into this repository (#11805)

* Remove misc wizer-related files

* Integrate the Wizer manifest with this repo's workspace

* Enable some more wasmtime features

* Get wizer tests pa

Integrate wizer into this repository (#11805)

* Remove misc wizer-related files

* Integrate the Wizer manifest with this repo's workspace

* Enable some more wasmtime features

* Get wizer tests passing in-repo

* Remove duplicate dummy wizer module

* Integer `wasmtime wizer` subcommand into the CLI

* Fully integrate wizer into `wasmtime` CLI

* Split `wasmtime run` into helper functions
* Split `Wizer::run` into helper functions
* Weave the two together in `wasmtime wizer`

The end goal is to have all CLI options in `wasmtime run` applicable for
`wasmtime wizer` as well with some light edits between the two. Overall
though we shouldn't have to proactively support commands in one or the
other and everything ideally should "just work".

* Fix clippy warnings and bench compiles

* Fix benchmarks

* Create a store-per-iteration
* Use the right wasms in the regex benchmark

* Get wizer fuzzer building again

* Get CLI working again

* Run rustfmt

* Remove precompiled wasms from the tree

35M for some wasms is a bit heavy so instead build them from source.

* Update vet configuration for fuzzers/tests

* Update publish script with wasmtime-wizer

* Fix clippy lint

* Some docs and more clippy lints

prtest:full

* Relax version requirement

* Try to fix asan build

* Remove rustflags too

* Un-exclude wizer

* Adjust publish script

* Update lock file after rebase

* Integrate bytecodealliance/wizer#139

Use deterministic results for relaxed simd operations by default.

* Handle preloads in wizer

* Appease clippy

* Use deterministic relaxed simd in wizer tests

show more ...


Revision tags: v37.0.2, v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0, 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, v32.0.0
# 3e406d2e 20-Mar-2025 Alex Crichton <[email protected]>

Add a `wasmtime objdump` subcommand (#10405)

This commit adds an `objdump` subcommand to the `wasmtime` CLI. Like all
other subcommands this can be disabled for a more minimal build of the
CLI as we

Add a `wasmtime objdump` subcommand (#10405)

This commit adds an `objdump` subcommand to the `wasmtime` CLI. Like all
other subcommands this can be disabled for a more minimal build of the
CLI as well. The purpose of this subcommand is to provide a
Wasmtime-specific spin on the venerable native `objdump` itself. Notably
this brings Wasmtime-specific knowledge for filtering functions, showing
Wasmtime metadata, etc.

This command is intended to look like `objdump` roughly but also has
configurable output with various flags and things that can be printed.
For now the main Wasmtime additions are showing the address map
section, stack map section, and trap section of a `*.cwasm` file.

This new subcommand replaces the infrastructure of the `disas` test
suite, and now that test suite uses `wasmtime objdump` to generate test
expectations. Additionally the subcommand replaces the Pulley `objdump`
example as a more full-featured objdump that also works natively with
Pulley.

The hope is that if we add more binary metadata in the future (such as
unwinding tables) that can be relatively easily added here for
exploration as well. Otherwise this is mostly just a developer
convenience for Wasmtime developers as well and hopefully doesn't cost
too much in maintenance burden.

Closes #10336

show more ...


Revision tags: v31.0.0, v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0, v28.0.1, v28.0.0, v27.0.0, v26.0.1, v25.0.3, v24.0.2, v26.0.0, v21.0.2, v22.0.1, v23.0.3, v25.0.2, v24.0.1
# 719d6739 26-Sep-2024 Alex Crichton <[email protected]>

Add a `wasmtime completion` subcommand (#9312)

* Add a `wasmtime completion` subcommand

This commit adds a new subcommand to the `wasmtime` CLI which can be
used to generate shell completions for t

Add a `wasmtime completion` subcommand (#9312)

* Add a `wasmtime completion` subcommand

This commit adds a new subcommand to the `wasmtime` CLI which can be
used to generate shell completions for the `wasmtime` version that is
installed. This is relatively easy to do with the `clap_complete` crate
which is also used with various other clap-based CLIs in Rust to
generate completions.

* Fix build

show more ...


Revision tags: v25.0.1, v25.0.0
# d0fbbba4 20-Aug-2024 Alex Crichton <[email protected]>

Change the CLI's name to `wasmtime` (#9153)

Currently `wasmtime --version` prints `wasmtime-cli ...` which is the
package name but this changes it to just `wasmtime` to match the
executable.


Revision tags: v24.0.0, v23.0.2, v23.0.1, v23.0.0, v22.0.0
# ffd6bb55 23-May-2024 Alex Crichton <[email protected]>

Remove support for Wasmtime 13-and-prior CLI (#8597)

This commit removes the support in the `wasmtime` CLI for old CLI
options which were present in Wasmtime 13 and prior. This compatibility
was add

Remove support for Wasmtime 13-and-prior CLI (#8597)

This commit removes the support in the `wasmtime` CLI for old CLI
options which were present in Wasmtime 13 and prior. This compatibility
was added in #7385 and backported to the Wasmtime 14 release #7395.
Wasmtime 14.0.0, which did not have this compatibility shim, was
released on 2023-10-20. Wasmtime 14.0.3, which restored compatibility
with this shim, was released on 2023-10-30. This means that Wasmtime
since 2023-10-30 has been warning users about differences in the old and
new CLI.

This commit will be released with Wasmtime 22 which will means that
users will have had an 8-month transition window for warnings to
migrate. The hope is that this is sufficient but it's also not too too
burdensome to carry for longer if necessary.

show more ...


Revision tags: v21.0.1, v21.0.0
# 0e9121da 16-May-2024 FrankReh <[email protected]>

Fix some typos (#8641)

* occurred

* winch typos

* tests typos

* cli typos

* fuzz typos

* examples typos

* docs typos

* crates/wasmtime typos

* crates/environ typos

* crates/cranelift typos

Fix some typos (#8641)

* occurred

* winch typos

* tests typos

* cli typos

* fuzz typos

* examples typos

* docs typos

* crates/wasmtime typos

* crates/environ typos

* crates/cranelift typos

* crates/test-programs typos

* crates/c-api typos

* crates/cache typos

* crates other typos

* cranelift/codegen/src/isa typos

* cranelift/codegen/src other typos

* cranelift/codegen other typos

* cranelift other typos

* ci js typo

* .github workflows typo

* RELEASES typo

* Fix clang-format documentation line

---------

Co-authored-by: Andrew Brown <[email protected]>

show more ...


Revision tags: v20.0.2, v20.0.1, v20.0.0, v17.0.3, v19.0.2, v18.0.4, v19.0.1, v19.0.0, v18.0.3, v18.0.2, v17.0.2
# 71951c9c 23-Feb-2024 Alex Crichton <[email protected]>

Enable compiling the Wasmtime CLI to Wasm (#7980)

* Enable compiling the Wasmtime CLI to Wasm

While not the most useful thing to do in the world it's kind of neat to
play around with. This builds o

Enable compiling the Wasmtime CLI to Wasm (#7980)

* Enable compiling the Wasmtime CLI to Wasm

While not the most useful thing to do in the world it's kind of neat to
play around with. This builds on the previous work to exclude the
runtime from the `wasmtime` crate so it's now possible to compile the
Wasmtime CLI's `compile` command, and only the `compile` command, to
wasm itself. This means you can run Wasmtime in Wasmtime!

* Fix warning on wasm

* Fix some feature combos

show more ...


Revision tags: v18.0.1, v18.0.0, v17.0.1, v17.0.0, v16.0.0
# f9f8a4df 08-Dec-2023 Xinzhao Xu <[email protected]>

Replace clap attributes with command and arg (#7658)


Revision tags: v15.0.1
# f050dd43 29-Nov-2023 Alex Crichton <[email protected]>

Add extended version information to `wasmtime --version` (#7610)

This commit adds some more information to `wasmtime --version` which
includes the git commit plus the git commit's date. This matches

Add extended version information to `wasmtime --version` (#7610)

This commit adds some more information to `wasmtime --version` which
includes the git commit plus the git commit's date. This matches `rustc
-V` for example which was additionally copied to `wasm-tools` and
mirrored as `wasm-tools -V`.

Personally I've found this useful since it can help point to exact
commits and additionally quickly get a sense of how old a version is
based on its commit date presented.

show more ...


Revision tags: v15.0.0, v14.0.4
# a00ff06c 30-Oct-2023 Alex Crichton <[email protected]>

Update some CLI usage help texts (#7408)

Updating a few locations that I missed from the previous updates.


Revision tags: 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
# d86afc02 19-Oct-2023 Alex Crichton <[email protected]>

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

* Move `wasmtime explore` behind a Cargo feature

Enable this Cargo feature by default, but enable building the CLI
without the `explore

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

* Move `wasmtime explore` behind a Cargo feature

Enable this Cargo feature by default, but enable building the CLI
without the `explore` subcommand.

* Move the `wast` subcommand behind a Cargo feature

* Move support for `wat` behind a CLI feature

This was already conditional in crates such as `wasmtime` and this makes
it an optional dependency of the CLI as well.

* Move CLI cache support behind a Cargo feature

Additionally refactor `wasmtime-cli-flags` to not unconditionally pull
in caching support by removing its `default` feature and appropriately
enabling 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 statements

This sets the static features of `log` and `tracing` to statically
remove all log statements from the binary to cut down on binary size.

* Move logging support behind a Cargo feature

Enables statically removing logging support in addition to the previous
compiling out log statements themselves.

* Move demangling support behind a Cargo feature

* Enable building the CLI without cranelift

Compile out the `compile` subcommand for example.

* Gate all profiling support behind one feature flag

This commit moves vtune/jitdump support behind a single `profiling`
feature flag that additionally includes the guest profiler dependencies
now 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

show more ...


# 079ddd4b 16-Oct-2023 Alex Crichton <[email protected]>

Minor logging tweaks (#7242)

Some things I noticed from #7239 which are very much not critical but I
figure might be nice-to-haves:

* Move the logging configuration to the `wasmtime-cli-flags` crat

Minor logging tweaks (#7242)

Some things I noticed from #7239 which are very much not critical but I
figure might be nice-to-haves:

* Move the logging configuration to the `wasmtime-cli-flags` crate with
the other logging configuration to keep it in one place.
* Remove `pretty_env_logger` since `tracing-subscriber` probably
supplants it.
* Don't explicitly inherit env vars in tests since that happens
automatically with `Command`.

show more ...


# f952ff27 13-Oct-2023 Pat Hickey <[email protected]>

wasmtime-cli: add tracing output on `WASMTIME_LOG` (#7239)

* wasmtime cli: install tracing-subscriber, listen to WASMTIME_LOG, log to stderr

* enable tracing colors

* audit supply chain for tracin

wasmtime-cli: add tracing output on `WASMTIME_LOG` (#7239)

* wasmtime cli: install tracing-subscriber, listen to WASMTIME_LOG, log to stderr

* enable tracing colors

* audit supply chain for tracing subscriber

show more ...


# 8a88ff6e 28-Sep-2023 Pat Hickey <[email protected]>

Wasi-http: support inbound requests (proxy world) (#7091)

* Move the incoming_handler impl into http_impl

* Remove the incoming handler -- we need to use it as a guest export

* Start adding a test

Wasi-http: support inbound requests (proxy world) (#7091)

* Move the incoming_handler impl into http_impl

* Remove the incoming handler -- we need to use it as a guest export

* Start adding a test-programs test for the server side of wasi-http

* Progress towards running a server test

* Implement incoming-request-method

* Validate outparam value

* Initial incoming handler test

* Implement more of the incoming api

* Finish the incoming api implementations

* Initial cut at `wasmtime serve`

* fix warning

* wasmtime-cli: invoke ServeCommand, and add enough stuff to the linker to run trivial test

* fix warnings

* fix warnings

* argument parsing: allow --addr to specify sockaddr

* rustfmt

* sync wit definitions between wasmtime-wasi and wasmtime-wasi-http

* cargo vet: add an import config and wildcard audit for wasmtime-wmemcheck

* cargo vet: audit signal-hook-registry

* Remove duplicate add_to_linker calls for preview2 interfaces

prtest:full

* Add a method to finish outgoing responses

Co-authored-by: Adam Foltzer <[email protected]>
Co-authored-by: Pat Hickey <[email protected]>

* Mark the result of the incoming_{request,response}_consume methods as own

* Explicit versions for http-body and http-body-util

* Explicit `serve` feature for the `wasmtime serve` command

* Move the spawn outside of the future returned by `ProxyHandler::call`

* Review feedback

---------

Co-authored-by: Trevor Elliott <[email protected]>
Co-authored-by: Adam Foltzer <[email protected]>

show more ...


Revision tags: minimum-viable-wasi-proxy-serve, v13.0.0, v12.0.2, v11.0.2, v10.0.2
# f7d0e870 13-Sep-2023 Alex Crichton <[email protected]>

Require Wasmtime options come before wasm modules (#6946)

This commit implements a new behavior for the CLI of the `wasmtime`
executable which will require that options for Wasmtime itself come
befo

Require Wasmtime options come before wasm modules (#6946)

This commit implements a new behavior for the CLI of the `wasmtime`
executable which will require that options for Wasmtime itself come
before the wasm module being run. Currently they're allowed to come
afterwards, but instead all arguments and flags coming after a module
will be interpreted as arguments for the module itself.

This feature has a bit of a storied history at this point, and the
breadcrumbs are:

* Originally landed in #6737
* Reverted for 12.0.0 in #6830
* Reverted for 13.0.0 in #6944

This PR is intended to be landed as a sibling of #6925, another
independent overhaul of Wasmtime's own options on the CLI, for the
Wasmtime 14.0.0 release. More information about the motivation for this
change, as well as consequences of the fallout, can be found on #6737.

show more ...


# df8d3698 31-Aug-2023 Alex Crichton <[email protected]>

Partially revert CLI argument changes from #6737 (#6944)

* Partially revert CLI argument changes from #6737

This commit is a partial revert of #6737. That change was reverted
in #6830 for the 12.0.

Partially revert CLI argument changes from #6737 (#6944)

* Partially revert CLI argument changes from #6737

This commit is a partial revert of #6737. That change was reverted
in #6830 for the 12.0.0 release of Wasmtime and otherwise it's currently
slated to get released with the 13.0.0 release of Wasmtime. Discussion
at today's Wasmtime meeting concluded that it's best to couple this
change with #6925 as a single release rather than spread out across
multiple releases. This commit is thus the revert of #6737, although
it's a partial revert in that I've kept many of the new tests added to
showcase the differences before/after when the change lands.

This means that Wasmtime 13.0.0 will exhibit the same CLI behavior as
12.0.0 and all prior releases. The 14.0.0 release will have both a new
CLI and new argument passing semantics. I'll revert this revert (aka
re-land #6737) once the 13.0.0 release branch is created and `main`
becomes 14.0.0.

* Update release notes

show more ...


Revision tags: v12.0.1, v12.0.0, v11.0.1, v11.0.0
# 80915565 20-Jul-2023 Alex Crichton <[email protected]>

Require wasmtime options are first when running modules (#6737)

* Require wasmtime options are first when running modules

Currently the way we've configured argument parsing it's valid to
execute a

Require wasmtime options are first when running modules (#6737)

* Require wasmtime options are first when running modules

Currently the way we've configured argument parsing it's valid to
execute a command such as:

wasmtime run foo.wasm -O

which is the same as:

wasmtime run -O foo.wasm

or otherwise all flags are attempted to be parsed as Wasmtime flags and
an error is generated when they're not wasmtime flags. I've personally
found this a bit confusing in the past and I find myself frequently
executing:

wasmtime run -- foo.wasm -other -arguments

While this works my general impression is that many other "wrapper
commands" don't behave this way and typically don't require `--` to pass
flags to the target executable. This commit reconfigures argument
parsing to consider any argument after the WebAssembly module itself to
be an argument to the wasm program rather than an argument to Wasmtime.
This means that all Wasmtime options must come between the `run` command
and the `foo.wasm` WebAssembly argument.

* Update wasi testsuite runner

* Support `wasmtime -- run`

Additionally use more clap features to avoid manually checking against
subcommands.

* Remove stale comment

* Reorder wasi-nn arguments

* Reorder more flags

* Fix unused import on Windows

* Don't run a stdio test on Windows

* Update gdb/lldb tests

* Don't assert that the write succeeds

prtest:full

show more ...


# 6d7bb360 15-Jul-2023 Alex Crichton <[email protected]>

Dependency gardening for Wasmtime (#6731)

* Remove deny.toml exception for wasm-coredump-builder

This isn't used any more so no need to continue to list this.

* Update Wasmtime's pretty_env_logger

Dependency gardening for Wasmtime (#6731)

* Remove deny.toml exception for wasm-coredump-builder

This isn't used any more so no need to continue to list this.

* Update Wasmtime's pretty_env_logger dependency

This 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 added
for that.

* Update criterion and clap dependencies

This commit started out by updating the `criterion` dependency to remove
an entry in `deny.toml`, but that ended up transitively requiring a
`clap` dependency upgrade from 3.x to 4.x because `criterion` uses
pieces of clap 4.x. Most of this commit is then dedicated to updating
clap 3.x to 4.x which was relatively simple, mostly renaming attributes
here and there.

* Update gimli-related dependencies

I originally wanted to remove the `indexmap` clause in `deny.toml` but
enough dependencies haven't updated from 1.9 to 2.0 that it wasn't
possible. In the meantime though this updates some various dependencies
to 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 new
crates. The tokio exemption was updated from its old version to the new
version and tokio remains un-audited.

* Update `syn` to 2.x.x

This required a bit of rewriting for the component-macro related bits
but otherwise was pretty straightforward. The `syn` 1.x.x track is still
present 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.x

This updates Wasmtime's dependency on the `bitflags` crate to the 2.x.x
track to keep it up-to-date.

* Update the cap-std family of crates

This bumps them all to the next major version to keep up with updates.
I've additionally added trusted entries for publishes of cap-std crates
from Dan.

There's still lingering references to rustix 0.37.x which will need to
get weeded out over time.

* Update memoffset dependency to latest

Avoids 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

show more ...


Revision tags: v10.0.1, v10.0.0, v9.0.4, v9.0.3, v9.0.2, v9.0.1, v9.0.0, v6.0.2, v7.0.1, v8.0.1, v8.0.0, v7.0.0
# 9ed441e6 11-Mar-2023 Nick Fitzgerald <[email protected]>

Introduce the `wasmtime-explorer` crate (#5975)

This implements Godbolt Compiler Explorer-like functionality for Wasmtime and
Cranelift. Given a Wasm module, it compiles the module to native code an

Introduce the `wasmtime-explorer` crate (#5975)

This implements Godbolt Compiler Explorer-like functionality for Wasmtime and
Cranelift. Given a Wasm module, it compiles the module to native code and then
writes a standalone HTML file that gives a split pane view between the WAT and
ASM disassemblies.

show more ...


Revision tags: v6.0.1, v5.0.1, v4.0.1, v6.0.0, v5.0.0, v4.0.0, v3.0.1, v3.0.0, v1.0.2, v2.0.2, v2.0.1, v2.0.0, v1.0.1, v1.0.0, v0.40.1, v0.40.0, v0.39.1, v0.38.3, v0.38.2, v0.39.0, v0.38.1, v0.38.0, v0.37.0
# 411f3d60 18-May-2022 Alex Crichton <[email protected]>

Tweak CLI fallback to the `run` command (#4161)

I ran across a case in Wasmtime today where a poor error message came
out of the CLI. For example before this commit you would get:

$ cargo ru

Tweak CLI fallback to the `run` command (#4161)

I ran across a case in Wasmtime today where a poor error message came
out of the CLI. For example before this commit you would get:

$ cargo run wast --wasm-features component-model foo.wast
error: Invalid value "wast" for '<MODULE>': module name cannot be the same as a subcommand

and now after this commit you get:

$ cargo run wast --wasm-features component-model foo.wast
error: Invalid value "component-model" for '--wasm-features <FEATURE,FEATURE,...>': unsupported WebAssembly feature 'component-model'

I believe this was an accidental regression from #4082 since Wasmtime
0.36.0 produces the error message as expected.

I opted to invert the conditional logic for falling back to the `run`
subcommand. Instead of having a small set of error kinds that print the
first-level error a small set of error kinds are now used to fall back
to the `run` subcommand by default. My hope is that as `ErrorKind` is
extended over time with various sorts of errors of parsing argumenst
this'll be more robust because most of the time we want the CLI
invocation to print out the normal CLI error, it's only in a select few
cases that using `run` is likely to succeed.

show more ...


# 5fe06f73 28-Apr-2022 Alex Crichton <[email protected]>

Update to clap 3.* (#4082)

* Update to clap 3.0

This commit migrates all CLI commands internally used in this project
from structopt/clap2 to clap 3. The intent here is to ensure that we're
usi

Update to clap 3.* (#4082)

* Update to clap 3.0

This commit migrates all CLI commands internally used in this project
from structopt/clap2 to clap 3. The intent here is to ensure that we're
using maintained versions of the dependencies as structopt and clap 2
are less maintained nowadays. Most transitions were pretty
straightforward and mostly dealing with structopt/clap3 differences.

* Fix a number of `cargo deny` errors

This commit fixes a few errors around duplicate dependencies which
arose from the prior update to clap3. This also uses a new feature in
`deny.toml`, `skip-tree`, which allows having a bit more targeted
ignores for skips of duplicate version checks. This showed a few more
locations in Wasmtime itself where we could update some dependencies.

show more ...


Revision tags: v0.36.0, v0.35.3, v0.34.2, v0.35.2, v0.35.1, v0.35.0, v0.33.1, v0.34.1, v0.34.0, v0.33.0, v0.32.1, v0.32.0, v0.31.0, v0.30.0
# 8ebaaf92 08-Sep-2021 Alex Crichton <[email protected]>

Remove the `wasmtime wasm2obj` command (#3301)

* Remove the `wasmtime wasm2obj` command

This commit removes the `wasm2obj` subcommand of the `wasmtime` CLI.
This subcommand has a very long histo

Remove the `wasmtime wasm2obj` command (#3301)

* Remove the `wasmtime wasm2obj` command

This commit removes the `wasm2obj` subcommand of the `wasmtime` CLI.
This subcommand has a very long history and dates back quite far. While
it's existed, however, it's never been documented in terms of the output
it's produced. AFAIK it's only ever been used for debugging to see the
machine code output of Wasmtime on some modules. With recent changes to
the module serialization output the output of `wasmtime compile`, the
`*.cwasm` file, is now a native ELF file which can be fed to standard
tools like `objdump`. Consequently I dont think there's any remaining
need to keep `wasm2obj` around itself, so this commit removes the
subcommand.

* More code to delete

* Try to fix debuginfo tests

show more ...


123