|
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 ...
|