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