en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#94740588 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/settings.rs Fri, 09 Jan 2026 19:15:48 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#90ac295e 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/settings.rs Mon, 19 May 2025 16:40:55 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#46098121 style: simplify string formatting (#9047)* style: simplify string formatting* fix: formatting in `benches/call.rs` List of files: /wasmtime-44.0.1/src/commands/settings.rs Wed, 31 Jul 2024 14:45:20 +0000 Hamir Mahal <hamirmahal@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#020751b0 Fix `wasmtime settings` command. (#8060)* Fix `wasmtime settings` command.Currently the `settings` command panics because the tunables are not set in thecompiler builder.This commit creates a default tunables based on either the target triple passedon the command line or uses the default for the host.Fixes #8058.* Additional clean up. List of files: /wasmtime-44.0.1/src/commands/settings.rs Thu, 07 Mar 2024 16:31:10 +0000 Peter Huene <peter@huene.dev> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#d4242001 Support compilation-only build by adding a `runtime` feature (#7766)* Add `runtime` feature to `wasmtime` crateThis feature can be disabled to build `wasmtime` only for compilation.This can be useful when cross-compiling, especially on a target thatcan't run wasmtime itself (e.g. `wasm32`).* prtest:full* don't round pages without runtime feature* fix async assertions* move profiling into runtime* enable runtime for wasmtime-wasi* enable runtime for c-api* fix build_artifacts in non-cache case* fix miri extensions* enable runtime for wast* enable runtime for explorer* support cranelift all-arch on wasm32* add doc links for `WeakEngine`* simplify lib runtime cfgs* move limits and resources to runtime* move stack to runtime* move coredump and debug to runtime* add runtime to coredump and async features* add wasm32 build job* combine engine modules* single compile mod* remove allow for macro paths* add comments List of files: /wasmtime-44.0.1/src/commands/settings.rs Mon, 29 Jan 2024 15:51:43 +0000 Adam Bratschi-Kaye <adam.bratschikaye@dfinity.org> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#f9f8a4df Replace clap attributes with command and arg (#7658) List of files: /wasmtime-44.0.1/src/commands/settings.rs Fri, 08 Dec 2023 16:19:10 +0000 Xinzhao Xu <z2d@jifangcheng.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#519808fc 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/settings.rs Sat, 28 Oct 2023 00:11:19 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#61e11a6c Remove usage of `BTreeMap` for compiler flags (#7287)* Remove usage of `BTreeMap` for compiler flagsNo need for a datastructure here really, a simple list with staticstrings works alright.* Fix winch compile and a warning* Fix test compile List of files: /wasmtime-44.0.1/src/commands/settings.rs Wed, 18 Oct 2023 21:38:14 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#9ec02f9d Decouple `serde` from its `derive` crate (#6917)By not activating the `derive` feature on `serde`, the compilation speedcan be improved by a lot. This is because `serde` can then compile inparallel to `serde_derive`, allowing it to finish compilation possiblyeven before `serde_derive`, unblocking all the crates waiting for`serde` to start compiling much sooner.As it turns out the main deciding factor for how long the compile time of aproject is, is primarly determined by the depth of dependencies ratherthan the width. In other words, a crate's compile times aren't affectedby how many crates it depends on, but rather by the longest chain ofdependencies that it needs to wait on. In many cases `serde` is part ofthat long chain, as it is part of a long chain if the `derive` featureis active:`proc-macro2` compile build script > `proc-macro2` run build script >`proc-macro2` > `quote` > `syn` > `serde_derive` > `serde` >`serde_json` (or any crate that depends on serde)By decoupling it from `serde_derive`, the chain is shortened and compiletimes get much better.Check this issue for a deeper elaboration:https://github.com/serde-rs/serde/issues/2584For `wasmtime` I'm seeing a reduction from 24.75s to 22.45s whencompiling in `release` mode. This is because wasmtime through `gimli`has a dependency on `indexmap` which can only start compiling when`serde` is finished, which you want to happen as early as possible sosome of wasmtime's dependencies can start compiling.To measure the full effect, the dependencies can't by themselvesactivate the `derive` feature. I've upstreamed a patch for`fxprof-processed-profile` which was the only dependency that activatedit for `wasmtime` (not yet published to crates.io). `wasmtime-cli` andco. may need patches for their dependencies to see a similarimprovement. List of files: /wasmtime-44.0.1/src/commands/settings.rs Tue, 29 Aug 2023 16:02:06 +0000 Christopher Serr <christopher.serr@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#8f23e5a6 `--json` option for `wasmtime settings` command (#5411)* - Added `--json` flag to settings command - Refactored gathering of data into a `Settings` struct which can be used in both human/machine readable paths - Split out human readable output to another function, it produces exactly the same result as before * Outputting JSON by hand formatting it. This approach has the advantage of not needing any extra dependencies (i.e.serde), but is obviously a bit ugly. * Rewritten JSON serialization to use serde * Commenting and formatting * Applied rustfmt * Reduced version of serde and serde_json to fix cargo vet errors * Updated cargo.lock to fix cargo vet errors List of files: /wasmtime-44.0.1/src/commands/settings.rs Mon, 12 Dec 2022 15:32:23 +0000 Martin Evans <martindevans@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#5fe06f73 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. List of files: /wasmtime-44.0.1/src/commands/settings.rs Thu, 28 Apr 2022 17:47:12 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#1c014d12 Cranelift: ensure ISA level needed for SIMD is present when SIMD is enabled. (#3816)Addresses #3809: when we are asked to create a Cranelift backend with shared flags that indicate support for SIMD, we should check that the ISA level needed for our SIMD lowerings is present. List of files: /wasmtime-44.0.1/src/commands/settings.rs Thu, 17 Feb 2022 01:29:30 +0000 Chris Fallin <chris@cfallin.org> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#ddfadaeb Add a cranelift compile-time feature to wasmtime (#3206)* Remove unnecessary into_iter/map Forgotten from a previous refactoring, this variable was already of the right type! * Move `wasmtime_jit::Compiler` into `wasmtime` This `Compiler` struct is mostly a historical artifact at this point and wasn't necessarily pulling much weight any more. This organization also doesn't lend itself super well to compiling out `cranelift` when the `Compiler` here is used for both parallel iteration configuration settings as well as compilation. The movement into `wasmtime` is relatively small, with `Module::build_artifacts` being the main function added here which is a merging of the previous functions removed from the `wasmtime-jit` crate. * Add a `cranelift` compile-time feature to `wasmtime` This commit concludes the saga of refactoring Wasmtime and making Cranelift an optional dependency by adding a new Cargo feature to the `wasmtime` crate called `cranelift`, which is enabled by default. This feature is implemented by having a new cfg for `wasmtime` itself, `cfg(compiler)`, which is used wherever compilation is necessary. This bubbles up to disable APIs such as `Module::new`, `Func::new`, `Engine::precompile_module`, and a number of `Config` methods affecting compiler configuration. Checks are added to CI that when built in this mode Wasmtime continues to successfully build. It's hoped that although this is effectively "sprinkle `#[cfg]` until things compile" this won't be too too bad to maintain over time since it's also an use case we're interested in supporting. With `cranelift` disabled the only way to create a `Module` is with the `Module::deserialize` method, which requires some form of precompiled artifact. Two consequences of this change are: * `Module::serialize` is also disabled in this mode. The reason for this is that serialized modules contain ISA/shared flags encoded in them which were used to produce the compiled code. There's no storage for this if compilation is disabled. This could probably be re-enabled in the future if necessary, but it may not end up being all that necessary. * Deserialized modules are not checked to ensure that their ISA/shared flags are compatible with the host CPU. This is actually already the case, though, with normal modules. We'll likely want to fix this in the future using a shared implementation for both these locations. Documentation should be updated to indicate that `cranelift` can be disabled, although it's not really the most prominent documentation because this is expected to be a somewhat niche use case (albeit important, just not too common). * Always enable cranelift for the C API * Fix doc example builds * Fix check tests on GitHub Actions List of files: /wasmtime-44.0.1/src/commands/settings.rs Wed, 18 Aug 2021 21:47:47 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#0313e30d Remove dependency on `TargetIsa` from Wasmtime crates (#3178)This commit started off by deleting the `cranelift_codegen::settings` reexport in the `wasmtime-environ` crate and then basically played whack-a-mole until everything compiled again. The main result of this is that the `wasmtime-*` family of crates have generally less of a dependency on the `TargetIsa` trait and type from Cranelift. While the dependency isn't entirely severed yet this is at least a significant start. This commit is intended to be largely refactorings, no functional changes are intended here. The refactorings are: * A `CompilerBuilder` trait has been added to `wasmtime_environ` which server as an abstraction used to create compilers and configure them in a uniform fashion. The `wasmtime::Config` type now uses this instead of cranelift-specific settings. The `wasmtime-jit` crate exports the ability to create a compiler builder from a `CompilationStrategy`, which only works for Cranelift right now. In a cranelift-less build of Wasmtime this is expected to return a trait object that fails all requests to compile. * The `Compiler` trait in the `wasmtime_environ` crate has been souped up with a number of methods that Wasmtime and other crates needed. * The `wasmtime-debug` crate is now moved entirely behind the `wasmtime-cranelift` crate. * The `wasmtime-cranelift` crate is now only depended on by the `wasmtime-jit` crate. * Wasm types in `cranelift-wasm` no longer contain their IR type, instead they only contain the `WasmType`. This is required to get everything to align correctly but will also be required in a future refactoring where the types used by `cranelift-wasm` will be extracted to a separate crate. * I moved around a fair bit of code in `wasmtime-cranelift`. * Some gdb-specific jit-specific code has moved from `wasmtime-debug` to `wasmtime-jit`. List of files: /wasmtime-44.0.1/src/commands/settings.rs Mon, 16 Aug 2021 14:55:39 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#e9f33fc6 Move all trampoline compilation to `wasmtime-cranelift` (#3176)* Move all trampoline compilation to `wasmtime-cranelift` This commit moves compilation of all the trampolines used in wasmtime behind the `Compiler` trait object to live in `wasmtime-cranelift`. The long-term goal of this is to enable depending on cranelift *only* from the `wasmtime-cranelift` crate, so by moving these dependencies we should make that a little more flexible. * Fix windows build List of files: /wasmtime-44.0.1/src/commands/settings.rs Thu, 12 Aug 2021 21:58:21 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#0ddfe97a Change how flags are stored in serialized modules.This commit changes how both the shared flags and ISA flags are stored in theserialized module to detect incompatibilities when a serialized module isinstantiated.It improves the error reporting when a compiled module has mismatched sharedflags. List of files: /wasmtime-44.0.1/src/commands/settings.rs Fri, 02 Apr 2021 02:32:15 +0000 Peter Huene <peter@huene.dev> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#9e7d2fed Sort output in `wasmtime settings`.This commit sorts the settings output by the `wasmtime settings` command. List of files: /wasmtime-44.0.1/src/commands/settings.rs Thu, 01 Apr 2021 18:22:01 +0000 Peter Huene <peter@huene.dev> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/settings.rs#abf3bf29 Add a `wasmtime settings` command to print Cranelift settings.This commit adds the `wasmtime settings` command to print out availableCranelift settings for a target (defaults to the host).The compile command has been updated to remove the Cranelift ISA options infavor of encouraging users to use `wasmtime settings` to discover what settingsare available. This will reduce the maintenance cost for syncing the compilecommand with Cranelift ISA flags. List of files: /wasmtime-44.0.1/src/commands/settings.rs Thu, 01 Apr 2021 05:44:13 +0000 Peter Huene <peter@huene.dev>