History log of /wasmtime-44.0.1/src/commands/settings.rs (Results 1 – 18 of 18)
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, 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, 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
# 90ac295e 19-May-2025 Alex Crichton <[email protected]>

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...


Revision tags: v32.0.0, 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, v25.0.1, v25.0.0, v24.0.0, v23.0.2
# 46098121 31-Jul-2024 Hamir Mahal <[email protected]>

style: simplify string formatting (#9047)

* style: simplify string formatting

* fix: formatting in `benches/call.rs`


Revision tags: v23.0.1, v23.0.0, v22.0.0, v21.0.1, v21.0.0, v20.0.2, v20.0.1, v20.0.0, v17.0.3, v19.0.2, v18.0.4, v19.0.1, v19.0.0, v18.0.3
# 020751b0 07-Mar-2024 Peter Huene <[email protected]>

Fix `wasmtime settings` command. (#8060)

* Fix `wasmtime settings` command.

Currently the `settings` command panics because the tunables are not set in the
compiler builder.

This commit creates a

Fix `wasmtime settings` command. (#8060)

* Fix `wasmtime settings` command.

Currently the `settings` command panics because the tunables are not set in the
compiler builder.

This commit creates a default tunables based on either the target triple passed
on the command line or uses the default for the host.

Fixes #8058.

* Additional clean up.

show more ...


Revision tags: v18.0.2, v17.0.2, v18.0.1, v18.0.0, v17.0.1
# d4242001 29-Jan-2024 Adam Bratschi-Kaye <[email protected]>

Support compilation-only build by adding a `runtime` feature (#7766)

* Add `runtime` feature to `wasmtime` crate

This feature can be disabled to build `wasmtime` only for compilation.
This can be u

Support compilation-only build by adding a `runtime` feature (#7766)

* Add `runtime` feature to `wasmtime` crate

This feature can be disabled to build `wasmtime` only for compilation.
This can be useful when cross-compiling, especially on a target that
can'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

show more ...


Revision tags: 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, v15.0.0, v14.0.4, v14.0.3
# 519808fc 28-Oct-2023 Alex Crichton <[email protected]>

Add compatibility shims for Wasmtime 13 CLI (#7385)

* Add compatibility shims for Wasmtime 13 CLI

This commit introduces a compatibility shim for the Wasmtime 13 CLI and
prior. The goal of this com

Add compatibility shims for Wasmtime 13 CLI (#7385)

* Add compatibility shims for Wasmtime 13 CLI

This commit introduces a compatibility shim for the Wasmtime 13 CLI and
prior. The goal of this commit is to address concerns raised in #7336
and other locations as well. While the new CLI cannot be un-shipped at
this point this PR attempts to ameliorate the situation somewhat through
a few avenues:

* A complete copy of the old CLI parser is now included in `wasmtime` by
default.
* The `WASMTIME_NEW_CLI=0` environment variable can force usage of the
old CLI parser for the `run` and `compile` commands.
* The `WASMTIME_NEW_CLI=1` environment variable can force usage of the
new CLI parser.
* Otherwise both the old and the new CLI parser are executed. Depending
on the result one is selected to be executed, possibly with a warning
printed.
* If both CLI parsers succeed but produce the same result, then no
warning is emitted and execution continues as usual.
* If both CLI parsers succeed but produce different results then a
warning is emitted indicating this. The warning points to #7384 which
has further examples of how to squash the warning. The warning also
mentions the above env var to turn the warning off. In this situation
the old semantics are used at this time instead of the new semantics.
It's intended that eventually this will change in the future.
* If the new CLI succeeds and the old CLI fails then the new semantics
are executed without warning.
* If the old CLI succeeds and the new CLI fails then a warning is issued
and the old semantics are used.
* If both the old and the new CLI fail to parse then the error message
for the new CLI is emitted.

Note that this doesn't add up to a perfect transition. The hope is that
most of the major cases of change at the very least have something
printed. My plan is to land this on `main` and then backport it to the
14.0.0 branch as a 14.0.3 release.

* Wordsmith messages

* Update messages

* More wording updates

* Fix grammar

* More updates

show more ...


Revision tags: v14.0.2, v13.0.1, v14.0.1, v14.0.0
# 61e11a6c 18-Oct-2023 Alex Crichton <[email protected]>

Remove usage of `BTreeMap` for compiler flags (#7287)

* Remove usage of `BTreeMap` for compiler flags

No need for a datastructure here really, a simple list with static
strings works alright.

* Fi

Remove usage of `BTreeMap` for compiler flags (#7287)

* Remove usage of `BTreeMap` for compiler flags

No need for a datastructure here really, a simple list with static
strings works alright.

* Fix winch compile and a warning

* Fix test compile

show more ...


Revision tags: minimum-viable-wasi-proxy-serve, v13.0.0, v12.0.2, v11.0.2, v10.0.2
# 9ec02f9d 29-Aug-2023 Christopher Serr <[email protected]>

Decouple `serde` from its `derive` crate (#6917)

By not activating the `derive` feature on `serde`, the compilation speed
can be improved by a lot. This is because `serde` can then compile in
parall

Decouple `serde` from its `derive` crate (#6917)

By not activating the `derive` feature on `serde`, the compilation speed
can be improved by a lot. This is because `serde` can then compile in
parallel to `serde_derive`, allowing it to finish compilation possibly
even 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 a
project is, is primarly determined by the depth of dependencies rather
than the width. In other words, a crate's compile times aren't affected
by how many crates it depends on, but rather by the longest chain of
dependencies that it needs to wait on. In many cases `serde` is part of
that long chain, as it is part of a long chain if the `derive` feature
is 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 compile
times get much better.

Check this issue for a deeper elaboration:
https://github.com/serde-rs/serde/issues/2584

For `wasmtime` I'm seeing a reduction from 24.75s to 22.45s when
compiling 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 so
some of wasmtime's dependencies can start compiling.

To measure the full effect, the dependencies can't by themselves
activate the `derive` feature. I've upstreamed a patch for
`fxprof-processed-profile` which was the only dependency that activated
it for `wasmtime` (not yet published to crates.io). `wasmtime-cli` and
co. may need patches for their dependencies to see a similar
improvement.

show more ...


Revision tags: v12.0.1, v12.0.0, v11.0.1, v11.0.0, 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, v6.0.1, v5.0.1, v4.0.1, v6.0.0, v5.0.0, v4.0.0
# 8f23e5a6 12-Dec-2022 Martin Evans <[email protected]>

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

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

show more ...


Revision tags: 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
# 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
# 1c014d12 17-Feb-2022 Chris Fallin <[email protected]>

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 SIM

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.

show more ...


Revision tags: v0.33.1, v0.34.1, v0.34.0, v0.33.0, v0.32.1, v0.32.0, v0.31.0, v0.30.0
# ddfadaeb 18-Aug-2021 Alex Crichton <[email protected]>

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 `wasmti

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

show more ...


# 0313e30d 16-Aug-2021 Alex Crichton <[email protected]>

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 playe

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

show more ...


# e9f33fc6 12-Aug-2021 Alex Crichton <[email protected]>

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
be

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

show more ...


Revision tags: v0.29.0, v0.28.0, v0.26.1, v0.27.0, v0.26.0
# 0ddfe97a 02-Apr-2021 Peter Huene <[email protected]>

Change how flags are stored in serialized modules.

This commit changes how both the shared flags and ISA flags are stored in the
serialized module to detect incompatibilities when a serialized modul

Change how flags are stored in serialized modules.

This commit changes how both the shared flags and ISA flags are stored in the
serialized module to detect incompatibilities when a serialized module is
instantiated.

It improves the error reporting when a compiled module has mismatched shared
flags.

show more ...


# 9e7d2fed 01-Apr-2021 Peter Huene <[email protected]>

Sort output in `wasmtime settings`.

This commit sorts the settings output by the `wasmtime settings` command.


# abf3bf29 01-Apr-2021 Peter Huene <[email protected]>

Add a `wasmtime settings` command to print Cranelift settings.

This commit adds the `wasmtime settings` command to print out available
Cranelift settings for a target (defaults to the host).

The co

Add a `wasmtime settings` command to print Cranelift settings.

This commit adds the `wasmtime settings` command to print out available
Cranelift settings for a target (defaults to the host).

The compile command has been updated to remove the Cranelift ISA options in
favor of encouraging users to use `wasmtime settings` to discover what settings
are available. This will reduce the maintenance cost for syncing the compile
command with Cranelift ISA flags.

show more ...