Changes in Cargo.toml

f248b5c0 - Config knobs and validation for record-replay (#12375)

Mon, 02 Feb 2026 04:30:42 +0000

Config knobs and validation for record-replay (#12375) List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

b11f8675 - Migrate CLI flags to `wasmtime::error` (#12260)

Wed, 07 Jan 2026 21:26:10 +0000

Migrate CLI flags to `wasmtime::error` (#12260) List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

afe9bcd1 - Bump Wasmtime to 40.0.0 (#11983)

Wed, 05 Nov 2025 01:03:14 +0000

Bump Wasmtime to 40.0.0 (#11983)Co-authored-by: Wasmtime Publish List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

02155232 - Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)

Wed, 15 Oct 2025 00:03:52 +0000

Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.This PR implements ideas from the [recent RFC] to serve as the basisfor Wasm (guest) debugging: it adds a stackslot to each functiontranslated from Wasm, stores to replicate Wasm VM state in thestackslot as the program runs, and metadata to describe the format ofthat state and allow reading it out at runtime.As an initial user of this state, this PR adds a basic "stack view"API that, from host code that has been called from Wasm, can examineWasm frames currently on the stack and read out all of their localsand stack slots.Note in particular that this PR does not include breakpoints,watchpoints, stepped execution, or any sort of user interface for anyof this; it is only a foundation.This PR still has a few unsatisfying bits that I intend to address:- The "stack view" performs some O(n) work when the view is initially taken, computing some internal data per frame. This is forced by the current design of `Backtrace`, which takes a closure and walks that closure over stack frames eagerly (rather than work as an iterator). It's got some impressive iterator-chain stuff going on internally, so refactoring it to the latter approach might not be *too* bad, but I haven't tackled it yet. A O(1) stack view, that is, one that does work only for frames as the host API is used to walk up the stack, is desirable because some use-cases may want to quickly examine e.g. only the deepest frame (say, running with a breakpoint condition that needs to read a particular local's value after each step).- It includes a new `Config::compiler_force_inlining()` option that is used only for testing that we get the correct frames after inlining. I couldn't get the existing flags to work on a Wasmtime config level and suspect there may be an existing bug there; I will try to split out a fix for it.This PR renames the existing `debug` option to `native_debug`, todistinguish it from the new approach.[recent RFC]: https://github.com/bytecodealliance/rfcs/pull/44* Update to new APIs on Cranelift side.* Test update.* Adjust objdump printing of InstPos on frame progpoints; and adjust progpoint collapsing.* Convert to iterator form.* Fix path in native-debug tests (debug -> native_debug rename).* Enforce that `debug_instrumentation` can only be enabled when feature is enabled.* Add missing assert.* Use builtin knob for forcing intra-module inlining instead.* Review feedback:- Make StackView own the current frame rather than handing it out. This prevents the current frame (`FrameView`) from walking away and hiding somewhere it shouldn't, to be used unsoundly later.- Assert no-GC during stack walk.* Merge debug-instrumentation hooks on FuncEnvironment into before/after hooks.* Review feedback: avoid downcasting funcs twice.* Add debug feature to `wasmtime` crate's defaults.* Review feedback: u32s for local and stack indices in debug host API.* Use *const u8 as stack pointers and `with_exposed_provenance` in debug API.* Remove some `srcloc` plumbing in Wasm translator.* Rename native-debug back to debug, and make the new thing "guest debugging".* rustfmt in debugging test.* fix disas test after guest-debug CLI option rename.* Review feedback: no separate debug-instrumentation hooks on FuncEnvironment.* Review feedback: update doc comment on `Config::guest_debug`.* Review feedback: rename `generate_debuginfo` to `debug_native` in tunables.* Review feedback: miscellaneous comments.* Review comment: fix wording in safety conditions.* revert wasi-common submodule update* Properly root values in debug frame slots.Fixes #11841.* Fix non-`debug`-feature build.* Review feedback: naming.* Ignore tests that compile modules in miri. List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

63d482c8 - Stack switching: Infrastructure and runtime support (#10388)

Wed, 04 Jun 2025 22:47:35 +0000

Stack switching: Infrastructure and runtime support (#10388)* [pr1] base* prtest:full* make sure to use ControlFlow result in trace_suspended_continuation* stack-switching: cleanup: remove stray c-api changesThese are remnants of unrelated wasmfx wasmtime experiments, possiblysuitable for later submission against upstream.* stack-switching: reuse async_stack_size* stack-switching: delete delete_me debugging* stack-switching: address feedback in environ::types* stack-switching: remove unused code from vmoffsets* stack-switching: drop dependency on std* stack-switching: add compilation checks to ci matrix* stack-switching: remove debug_println cruft* stack-switching: export environ consts consistently* stack-switching: export vm pub items consistently* table_pool: reduced capacity for large elementsVMContRef elements which takes up two words and we don't want todouble the size of all tables in order to support storing these.This change changes the table to target storing the requestedmax number of elements if they are "nominally" sized with(potentially) reduced capacity for non-nominally sized types whenencountered.Continuations are the only type of element which may result infewer table slots being available than requested.* stack-switching: extend conditional compilationA fair bit of the definitions for stack switching are stillenabled, but this patch takes things a bit further to avoidcompilation problems; notably, cont_new is now not compiledin unless the feature is enabled.* stack-switching: formatting fixes* stack-switching: address new clippy checksIn addition, to get clippy to fully pass, plumbed inadditional config to make winch paths happy; there's noimpl for winch yet but plumbing through the feature isrequired to make paths incorporating macros at variouslayers satisfied (and it is expected we'll use thefeatures in the future).* stack-switching: more conditional compilation fixes* stack-switching: additional conditional compile on table builtins for continuations* stack-switching: additional conditional compile fixes* stack-switching: additional conditional compile in store* stack-switching: remove overly strict assertion* stack-switching: remove errantly dropped no_mangle in config c-api* stack-switching: VMContObj::from_raw_parts* stack-switching: remove duplicate async_stack_size feature check* stack-switching: VMArray -> VMHostArray* stack-switching: remove unnecessary clippy exception* stack-switching: fix docs referenced VMRuntimeLimits* stack-switching: fix doc typo* stack-switching: follow recommendations for type casts* stack-switching: use usize::next_multiple_of* stack-switching: update outdated comment* stack-switching: use feature gate instead of allow(dead_code)* stack-switching: rework backtrace using chunks/zip* stack-switching: move tests to footer moduleThis is a bit more consistent with the prevailing stylein tree and (subjectively) makes finding the testsas a reader more straightforward.Tests left unchanged sans some import cleanup.* stack-swictchding: verify stack_chain offsets at runtime* fixup! stack-switching: use feature gate instead of allow(dead_code)* stack-switching: document continuation roots tracing using match arms---------Co-authored-by: Paul Osborne List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

bda83128 - Remove humantime crate dependency (#10379)

Wed, 12 Mar 2025 05:21:18 +0000

Remove humantime crate dependency (#10379)Turns out this has been unmaintained for quite some time now. Itadditionally is only a fringe benefit so hand-write a few parsers toreplace it.Closes #10378 List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

2a5c141c - Create wasmtime::Config from toml (#9811)

Mon, 27 Jan 2025 23:28:22 +0000

Create wasmtime::Config from toml (#9811)* Create wasmtime::Config from toml, add --config CLI flag* Add cli tests List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

ba4e22bc - Make it easier to reuse fuzzing configuration on the CLI (#10123)

Mon, 27 Jan 2025 21:34:55 +0000

Make it easier to reuse fuzzing configuration on the CLI (#10123)* Make it easier to reuse fuzzing configuration on the CLIDuring fuzzing we emit a debug log of configured options to assist withreproducing fuzz test cases outside of the fuzzing harness. Mappingoptions the fuzzer is using though to CLI flags, for example, is a bitof an art though and not obvious. Just today we've got a fuzz bug and Icouldn't figure out how to reproduce on the CLI and it turns out theissue was that I was forgetting a flag that was being configured inresponse to another flag. I got a bit fed up with constantly trying tomap one to the other, so I've decided to fix things.This commit adds a `Display for CommonOptions` implementation to the`wasmtime-cli-flags` crate. This is built on the same macro-constructioninfrastructure of all our flags making it a relatively low one-time-costto implement this. Each option value now implements not only parsing butprinting as well.Next the `wasmtime-fuzzing` crate was updated to create a`CommonOptions` first which is then in turn used to create a`wasmtime::Config`. This provides a layer to insert a log statement withto emit all configuration options in a form that can be easilycopy/pasted to the CLI to reproduce.Overall after doing this I was able to quickly reproduce the bug inquestion (yay!). The CLI flag logging is pretty verbose right now sincethe fuzzing infrastructure sets many settings redundantly to theirdefaults, but reducing flags to a minimum is expected to be relativelyeasy compared to otherwise trying to extract the options.* Fix build and dependencies from wasmtime-fuzzing* Always provide `wasmtime::MpkEnabled`It's an otherwise very small `enum` which makes it easier toconditionally compile `wasmtime-cli-flags`* Frob some crate features some more* Fix specification of `wasmtime_linkopt_force_jump_veneer` option List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

7f9049b9 - Replace `signals-based-traps` with auto-detection (#9941)

Wed, 15 Jan 2025 01:15:14 +0000

Replace `signals-based-traps` with auto-detection (#9941)* Replace `signals-based-traps` with auto-detectionThis commit refactors the platform support of the `wasmtime` crateitself to remove the previously added `signals-based-traps` feature infavor of auto-detecting whether it's there or not. The `build.rs`script for the `wasmtime` crate will now detect the target platform andauto-enable this feature as necessary.The `signals-based-traps` cargo feature is removed and split into twocustom `#[cfg]` directives that the build script sets:* `has_virtual_memory` - this is used to gate mmap implementations for example. This is enabled on `unix || windows` and will be off for `no_std` targets for example. This is split out of "signals-based-traps" to better handle platforms like iOS which have virtual memory but don't execute native code (removing the need for native signals).* `has_native_signals` - gates signal handlers on Unix for example. This is disabled on MIRI but otherwise enabled for `unix || windows`. This is intended to in the future get disabled for iOS by default for example since it's not necessary when using Pulley. This is additionally off-by-default for `no_std` platforms.Two new crate features were added for `no_std` or "custom" platforms toopt-in to the `wasmtime-platform.h` C APIs for implementing virtualmemory and signals. These are used in the `min-platform` embedding example.This commit additionally updates some various documentation here andthere to be more up-to-date.* Update CI configuration* Fix compile warnings* Fix test on miri* Fix more tests on miri* Fix some warnings* Another round of miri/CI attempts/fixesprtest:full List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

a1511a09 - Enable `pulley` by default for the `wasmtime` CLI (#9983)

Sat, 11 Jan 2025 23:29:24 +0000

Enable `pulley` by default for the `wasmtime` CLI (#9983)Now that pulley is nearing completion this makes it more useful to testout the interpreter on the CLI by having it available by default on allplatforms. List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

0da04430 - Don't forcibly enable `gc` feature with cli-flags crate (#9887)

Fri, 20 Dec 2024 21:30:34 +0000

Don't forcibly enable `gc` feature with cli-flags crate (#9887)* Don't forcibly enable `gc` feature with cli-flags crateHelps keep the `gc` feature out of the "min" build.* Fix standalone build of wasmtime-cli-flags List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

d3132c9d - Add a `signals-based-traps` Cargo compile-time feature (#9614)

Tue, 19 Nov 2024 19:21:36 +0000

Add a `signals-based-traps` Cargo compile-time feature (#9614)* Gate signal handlers behind a new Cargo featureThis commit adds a new on-by-default Cargo feature to the `wasmtime`crate named `signals-based-traps`. This is modeled after the`Config::signals_based_traps` configuration at runtime and can be usedto statically disable the use of signal handlers in Wasmtime. Thisnotably reduces the number of platform dependencies that Wasmtime hasand provides a mode of avoiding relying on signals altogether.This introduces a new `MallocMemory` which is a linear memory backed bythe system allocator. This new type of memory is enabled when virtualmemory guards are disabled and signals-based-traps are disabled. Thismeans that this new type of memory will be candidate for fuzzing forexample.prtest:full* Fix rebase conflict* Refactor `MmapVec` documentation and representation* Remove no-longer-needed `Arc`* Document it may be backed by `Vec` List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

83bf774d - Add the "null" garbage collector (#9484)

Thu, 31 Oct 2024 17:46:17 +0000

Add the "null" garbage collector (#9484)* Add the "null" garbage collectorThe null collector does not actually collect any garbage, it simplybump-allocates until the heap is exhausted, at which point further allocationattempts will fail. It does not require any GC barriers.Users can configure which collector to use via the `wasmtime::Config::collector`method or the `-C collector=drc|null` CLI flag. The `wasmtime::Collector` enumeration,similar to the `wasmtime::Strategy` enumeration but for choosing a collectorrather than a compiler, additionally has a table summarizing the properties andcharacteristics of our current set of collector implementations.Finally, we also run `.wast` tests that exercise GC types under both the DRC andnull collectors. I tried to avoid running tests that are not related to GC underboth configurations just to avoid a combinatorial blow up.* cargo fmt* fix +gc -gc-null -gc-drc build* Fix some warnings in various cargo feature combo builds* Fix some more warnings in certain build configs* Fix unit tests for null GC* Fill in some placeholder comments that I forgot to write* Fix issues where we ask for a GC store when we don't actually need oneWhich was causing test failures, since we no longer return a GC store with adummy heap.* Add fuzzing config support for different collectors* address review feedback* fix cmake tests* Fix test compilation after rebase* Fix GC tests under MIRI List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

83029e3f - Add `rust-version.workspace = true` to all crates (#9112)

Mon, 12 Aug 2024 15:52:11 +0000

Add `rust-version.workspace = true` to all crates (#9112)Right now this is only on some crates such as `wasmtime` itself and`wasmtime-cli`, but by applying it to all crates it helps with versionselection of those using just Cranelift for example. List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

47af01f1 - Fix build of `wasmtime-cli` with only the pooling allocator enabled (#8891)

Tue, 02 Jul 2024 01:34:46 +0000

Fix build of `wasmtime-cli` with only the pooling allocator enabled (#8891)Fixes #8889 List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

0f48f939 - Disable memory protection keys by default at compile time (#8813)

Fri, 14 Jun 2024 23:08:43 +0000

Disable memory protection keys by default at compile time (#8813)* Disable memory protection keys by default at compile timeThis commit gates memory protection keys behind a new Cargo featurewhich is disabled by default. Memory protection keys are alreadydisabled by default on all platforms and are only configured to possiblywork with Linux x64. When enabled, however, it unconditionally adds asmall amount of overhead to WebAssembly entries/exits even if thefeature is disabled at runtime for the same reason that the `call-hook`feature adds overhead. With `call-hook` being disabled by defaultin #8808 it seemed reasonable to additionally gate memory protectionkeys to avoid needing to disable features in Wasmtime to get the bestperformance wasm<->host calls.* Enable Wasmtime feature for fuzzing List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

81a89169 - Add support for `#![no_std]` to the `wasmtime` crate (#8533)

Sat, 04 May 2024 22:02:26 +0000

Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime's platform support to no longer require anopt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becomingofficially supported this should provide a better onboarding experiencewhere the fallback custom platform is used. This will cause linkererrors if the symbols aren't implemented and searching/googling shouldlead back to our docs/repo (eventually, hopefully).* Change Wasmtime's TLS state to a single pointerThis commit updates the management of TLS to rely on just a singlepointer rather than a pair of a pointer and a `bool`. Additionallymanagement of the TLS state is pushed into platform-specific modules toenable different means of managing it, namely the "custom" platform nowhas a C function required to implement TLS state for Wasmtime.* Delay conversion to `Instant` in atomic intrinsicsThe `Duration` type is available in `no_std` but the `Instant` type isnot. The intention is to only support the `threads` proposal if `std` isactive but to assist with this split push the `Duration` further intoWasmtime to avoid using a type that can't be mentioned in `no_std`.* Gate more parts of Wasmtime on the `profiling` featureMove `serde_json` to an optional dependency and gate the guest profilerentirely on the `profiling` feature.* Refactor conversion to `anyhow::Error` in `wasmtime-environ`Have a dedicated trait for consuming `self` in addition to a`Result`-friendly trait.* Gate `gimli` in Wasmtime on `addr2line`Cut down the dependency list if `addr2line` isn't enabled since thenthe dependency is not used. While here additionally lift the versionrequirement for `addr2line` up to the workspace level.* Update `bindgen!` to have `no_std`-compatible outputPull most types from Wasmtime's `__internal` module as the source oftruth.* Use an `Option` for `gc_store` instead of `OnceCell`No need for synchronization here when mutability is already available inthe necessary contexts.* Enable embedder-defined host feature detection* Add `#![no_std]` support to the `wasmtime` crateThis commit enables compiling the `runtime`, `gc`, and `component-model`features of the `wasmtime` crate on targets that do not have `std`. Thistags the crate as `#![no_std]` and then updates everything internally toimport from `core` or `alloc` and adapt for the various idioms. Thisended up requiring some relatively extensive changes, but nothing tootoo bad in the grand scheme of things.* Require `std` for the perfmap profiling agentprtest:full* Fix build on wasm* Fix windows build* Remove unused import* Fix Windows/Unix build without `std` feature* Fix some doc links* Remove unused import* Fix build of wasi-common in isolation* Fix no_std build on macos* Re-fix build* Fix standalone build of wasmtime-cli-flags* Resolve a merge conflict* Review comments* Remove unused import List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

83b859e5 - Gate support for the wasm `threads` proposal behind a Cargo feature (#8260)

Fri, 29 Mar 2024 08:30:15 +0000

Gate support for the wasm `threads` proposal behind a Cargo feature (#8260)* Gate support for the wasm `threads` proposal behind a Cargo featureThis commit moves support for the `threads` proposal behind a newon-by-default Cargo feature: `threads`. This is intended to supportbuilding Wasmtime with fewer runtime dependencies such as those requiredfor the atomic operations on memories.This additionally adds the `gc` feature in a few missing places too.* Fix compile of C API without threads List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

dd0364d3 - Wasmtime: Add a `gc` cargo feature (#7975)

Fri, 23 Feb 2024 17:14:21 +0000

Wasmtime: Add a `gc` cargo feature (#7975)* Wasmtime: Add a `gc` cargo featureThis controls whether support for `ExternRef` and its associated deferred,reference-counting garbage collector is enabled at compile time or not. It willalso be used for similarly for Wasmtime's full Wasm GC support as that getsadded.* Add CI for `gc` Cargo feature* Cut down on the number of `#[cfg(feature = "gc")]`s outside the implementation of `[VM]ExternRef`* Fix wasmparser reference types configuration with GC disabled/enabled* More config fix* doc cfg* Make the dummy `VMExternRefActivationsTable` inhabited* Fix winch tests* final review bits* Enable wasmtime's gc cargo feature for the C API* Enable wasmtime's gc cargo feature from wasmtime-cli-flags* enable gc cargo feature in a couple other crates List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml

5856590f - Configure workspace lints, enable running some Clippy lints on CI (#7561)

Mon, 20 Nov 2023 23:23:41 +0000

Configure workspace lints, enable running some Clippy lints on CI (#7561)* Configure Rust lints at the workspace levelThis commit adds necessary configuration knobs to have lints configuredat the workspace level in Wasmtime rather than the crate level. Thisuses a feature of Cargo first released with 1.74.0 (last week) of the`[workspace.lints]` table. This should help create a more consistent setof lints applied across all crates in our workspace in addition topossibly running select clippy lints on CI as well.* Move `unused_extern_crates` to the workspace levelThis commit configures a `deny` lint level for the`unused_extern_crates` lint to the workspace level rather than theprevious configuration at the individual crate level.* Move `trivial_numeric_casts` to workspace level* Change workspace lint levels to `warn`CI will ensure that these don't get checked into the codebase andotherwise provide fewer speed bumps for in-process development.* Move `unstable_features` lint to workspace level* Move `unused_import_braces` lint to workspace level* Start running Clippy on CIThis commit configures our CI to run `cargo clippy --workspace` for allmerged PRs. Historically this hasn't been all the feasible due to theamount of configuration required to control the number of warnings onCI, but with Cargo's new `[lint]` table it's possible to have aone-liner to silence all lints from Clippy by default. This commit bydefault sets the `all` lint in Clippy to `allow` to by-default disablewarnings from Clippy. The goal of this PR is to enable selective accessto Clippy lints for Wasmtime on CI.* Selectively enable `clippy::cast_sign_loss`This would have fixed #7558 so try to head off future issues with thatby warning against this situation in a few crates. This lint is stillquite noisy though for Cranelift for example so it's not worthwhile atthis time to enable it for the whole workspace.* Fix CI errorprtest:full List of files: /wasmtime-44.0.1/crates/cli-flags/Cargo.toml