Changes in module.rs

94740588 - Migrate the Wasmtime CLI to `wasmtime::error` (#12295)

Fri, 09 Jan 2026 19:15:48 +0000

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/tests/all/module.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

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/tests/all/module.rs

99efc20b - Add Engine/Component::deserialize_raw (#10321)

Thu, 06 Mar 2025 18:16:50 +0000

Add Engine/Component::deserialize_raw (#10321)* Add Engine/Component::deserialize_rawFor targets without virtual memory support, the only mechanism forload code previously was to copy bytes from a provided slice intoa separate, owned, allocated buffer containing a copy of the serializedmodule contents. This is expensive for constrained targets andprohibits embedded runtimes like doing things like running codedirectly out of memory-mapped devices such as NOR flash.The tradeoff for directly using the externally owned memory is thatthe caller must ensure that the code memory will not be writtento for the lifetime of the CodeMemory.Loading code from externally owned memory is supported for allconfigurations but is expected to fail to deserialize on platformsthat suport virtual memory and are attempting to load modulesor components that require that the memory be made executable(native code rather than pulley).https://github.com/bytecodealliance/wasmtime/issues/10245* Fix tests for s390xPreviously, there was a bad assumption that pulley32/64 were theonly targets but there's also the "be" variants. Use the`pulley_host` helper to better get the right pulley targetfor the host. List of files: /wasmtime-44.0.1/tests/all/module.rs

6ac02e10 - Optimize MIRI execution time in CI (#10038)

Fri, 17 Jan 2025 15:33:11 +0000

Optimize MIRI execution time in CI (#10038)* Optimize MIRI execution time in CI* Disable Cranelift optimizations and use single_pass register allocation by default.* Ignore a number of tests that are compiling wasm which we generally don't want to do under MIRI.* Fix CI build List of files: /wasmtime-44.0.1/tests/all/module.rs

48f4621f - Run the full test suite on 32-bit platforms (#9837)

Wed, 15 Jan 2025 18:43:18 +0000

Run the full test suite on 32-bit platforms (#9837)* Run the full test suite on 32-bit platformsThis commit switches to running the full test suite in its entirety(`./ci/run-tests.sh`) on 32-bit platforms in CI in addition to 64-bitplatforms. This notably adds i686 and armv7 as architectures that aretested in CI.Lots of little fixes here and there were applied to a number of tests.Many tests just don't run on 32-bit platforms or a platform withoutCranelift support, and they've been annotated as such where necessary.Other tests were adjusted to run on all platforms a few minor bug fixesare here as well.prtest:full* Fix clippy warning* Get wasm code working by default on 32-bitDon't require the `pulley` feature opt-in on 32-bit platforms to getwasm code running.* Fix dead code warning* Fix build on armv7* Fix test assertion on armv7* Review comments* Update how tests are skipped* Change how Pulley is defaultedDefault to pulley in `build.rs` rather than in `Cargo.toml` to make iteasier to write down the condition and comment what's happening. Thismeans that the `pulley-interpreter` crate and pulley support inCranelift is always compiled in now and cannot be removed. This shouldhopefully be ok though as the `pulley-interpreter` crate is stillconditionally used (meaning it can get GC'd) and the code-size ofCranelift is not as important as the runtime itself.* pulley: Save/restore callee-save state on traps* Fewer clippy warnings about casts* Use wrapping_add in `g32_addr`, fixing arm test List of files: /wasmtime-44.0.1/tests/all/module.rs

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/tests/all/module.rs

1c970440 - Make module validation deterministic in case of multiple errors (#9947)

Thu, 09 Jan 2025 15:50:49 +0000

Make module validation deterministic in case of multiple errors (#9947)* make validation deterministic in case of multiple errors* test flag* smaller test---------Co-authored-by: Michael Weigelt List of files: /wasmtime-44.0.1/tests/all/module.rs

7a28a5b9 - Remove static/dynamic memories from public docs (#9545)

Tue, 05 Nov 2024 01:05:58 +0000

Remove static/dynamic memories from public docs (#9545)* Remove static/dynamic memories from public docsThis commit removes the terminology of "static" and "dynamic" memoriesfrom the public-facing documentation of Wasmtime, notably on the`Config` structure and its various configuration settings. The goal ofthis commit is in the same vein as #9543 which is to simplify the memorysettings of Wasmtime for users in this case.This change doesn't actually have any code changes beyond renames (andhandling now-deprecated CLI options). The goal of this commit is tobasically rewrite how we document the effect of various settings ofWasmtime. Notably:* `Config::static_memory_maximum_size` is now `memory_reservation`.* `Config::static_memory_forced` is now `memory_reservation_is_maximum`.* `Config::dynamic_memory_reserved_for_growth` is now `memory_reservation_for_growth`.Documentation for all of these options has been rewritten and updated totake into account the removal of "dynamic" and "static" terminology.Additionally more words have been written about the various effects ofeach setting and how things related to wasm features such as index typesizes and custom page sizes.The rewritten documentation is intended to basically already match whatWasmtime does today. I believe that all of these settings are useful inone form or another so none have been dropped but the updateddocumentation is intended to help simplify the mental model for howthey're processed internally and how they affect allocations and such.* Fix how the setting is flipped* Review comments List of files: /wasmtime-44.0.1/tests/all/module.rs

e600891f - Unbreak CI on release branch (#9411)

Wed, 09 Oct 2024 15:16:54 +0000

Unbreak CI on release branch (#9411)Ignore new tests on MIRIprtest:full List of files: /wasmtime-44.0.1/tests/all/module.rs

0ebe54d0 - Merge commit from fork

Wed, 09 Oct 2024 14:28:12 +0000

Merge commit from fork* Fix a race condition in the Wasm type registryUnder certain concurrent event orderings, the type registry was susceptible todouble-unregistration bugs due to a race condition.Consider the following example where we have threads `A` and `B`, an existingrec group entry `E`, and another rec group entry `E'` that is a duplicate of`E`:| Thread A | Thread B ||-----------------------------------|--------------------------------|| `acquire(type registry lock)` | || | `decref(E) --> 0` || | `block_on(type registry lock)` || `register(E') == incref(E) --> 1` | || `release(type registry lock)` | || `decref(E) --> 0` | || `acquire(type registry lock)` | || `unregister(E)` | || `release(type registry lock)` | || | `acquire(type registry lock)` || | `unregister(E)` !!!!!! |As you can see, in the above event ordering, we would unregister `E` twice,leading to panics and potential type registry corruption.This commit adds an `unregistered` flag to each entry which is set when wecommit to unregistering the entry and while we hold the type registry lock. Whenwe are considering unregistering an entry at the beginning of`TypeRegistryInner::unregister_entry`, because we observed a zero-registrationscount for that entry and then waited on the type registry's lock, we now checkif that flag is already set (by some concurrent unregistration that happenedbetween observing the zero-registrations count and acquiring the lock) before weactually perform the unregistration.Furthermore, in the process of writing a smoke test for concurrent module (andtherefore type) loading and unloading, I discovered an index out-of-bounds panicduring Wasm-to-CLIF module translation. This commit also includes the one-linefix for that bug and a `.wast` regression test for it as well.* Update test to trigger case requiring `unregistered` flag* Add another test further stressing concurrent interactionsTry to get a module's function type to get typed the wrong way and/orget wasm to call with the wrong signature.---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/tests/all/module.rs

974c3245 - Simplify ABI selection and tail call integration (#9061)

Fri, 02 Aug 2024 16:16:01 +0000

Simplify ABI selection and tail call integration (#9061)This commit simplifies the selection of an ABI for wasm functions nowthat all Cranelift backends implement tail calls. All wasm functions usethe `Tail` calling convention except when the `winch_callable` tunableis enabled meaning that Winch-generated functions are being called.This then additionally simplifies the activation of the tail callproposal. It's not unconditionally active and the same across allcompilers. The Winch compiler is updated to return an error forunsupported instructions rather than panicking so the embedder API issuitable for feeding unsupported modules to Winch. This means that tailcalls in Winch behaves similarly to GC in Cranelift or other unsupportedproposals like SIMD in Winch. List of files: /wasmtime-44.0.1/tests/all/module.rs

a7272b82 - s390x: Support tail calls (#9052)

Thu, 01 Aug 2024 20:06:42 +0000

s390x: Support tail calls (#9052)This adds support for a newly defined tail-call ABI for s390xas well as supporting tail calls themselves.We now use the tail-call ABI by default for Wasmtime, andenable tail calls by default.This also allows getting rid of a number of special caseand test exclusions for s390x.Fixes: https://github.com/bytecodealliance/wasmtime/issues/6530 List of files: /wasmtime-44.0.1/tests/all/module.rs

46098121 - style: simplify string formatting (#9047)

Wed, 31 Jul 2024 14:45:20 +0000

style: simplify string formatting (#9047)* style: simplify string formatting* fix: formatting in `benches/call.rs` List of files: /wasmtime-44.0.1/tests/all/module.rs

7bf2b8fb - Wasmtime: remove indirect-call caching. (#8881)

Thu, 27 Jun 2024 17:21:25 +0000

Wasmtime: remove indirect-call caching. (#8881)In the original development of this feature, guided by JS AOTcompilation to Wasm of a microbenchmark heavily focused on IC sites, Iwas seeing a ~20% speedup. However, in more recent measurements, on fullprograms (e.g., the Octane benchmark suite), the benefit is more like5%.Moreover, in #8870, I attempted to switch over to a direct-mapped cache,to address a current shortcoming of the design, namely that it has ahard-capped number of callsites it can apply to (50k) to limit impact onVMContext struct size. With all of the needed checks for correctness,though, that change results in a 2.5% slowdown relative to no caching atall, so it was dropped.In the process of thinking through that, I discovered the current designon `main` incorrectly handles null funcrefs: it invokes a null code pointer,rather than loading a field from a null struct pointer. The latter wasspecifically designed to cause the necessary Wasm trap in #8159, but Ihad missed that the call to a null code pointer would not have the sameeffect. As a result, we actually can crash the VM (safely at least, butstill no good vs. a proper Wasm trap!) with the feature enabled. (It'soff by default still.) That could be fixed too, but at this point withthe small benefit on real programs, together with the limitation onmodule size for full benefit, I think I'd rather opt for simplicity andremove the cache entirely.Thus, this PR removes call-indirect caching. It's not a direct revertbecause the original PR refactored the call-indirect generation intosmaller helpers and IMHO it's a bit nicer to keep that. But otherwiseall traces of the setting, code pre-scan during compilation and specialconditions tracked on tables, and codegen changes are gone. List of files: /wasmtime-44.0.1/tests/all/module.rs

af59c4d5 - Make module ids unique per-process, not per-engine (#8758)

Fri, 07 Jun 2024 22:24:45 +0000

Make module ids unique per-process, not per-engine (#8758)* Make module ids unique per-process, not per-engineCurrently all instances of `wasmtime::Module` have a unique 64-bit idembedded into them. This ID was originally only used for affinity in thepooling allocator as a quick check of module equality. This use caseonly required engine-local ids so the initial implementation had an IDallocator per-engine.Later, however, this id was reused for `wasmtime::ModuleExport` whichwas intended to skip the string lookup for an export at runtime. Thisalso stored a module id but it did not store an engine identifier. Thismeant that it's possible to mix these up and pass the wrong export tothe wrong engine. This behavior can lead to a runtime panic in Wasmtime.This commit fixes this by making the module identifier be globalper-process instead of per-engine. This mirrors how store IDs areallocated where they're per-process instead of per-engine. The samelogic for why store IDs are unlikely to be exhausted applies here toowhere this 64-bit space of identifiers is unlikely to be exhausted.* Fix warnings* Fix tests List of files: /wasmtime-44.0.1/tests/all/module.rs

4896b663 - Fix tail calls being turned on by default (#8682)

Wed, 22 May 2024 21:23:39 +0000

Fix tail calls being turned on by default (#8682)* Fix tail calls being turned on by defaultLogic in `Config` to conditionally enable tail calls wasn't handling thecase where the configured compiler strategy was `Strategy::Auto` meaningthat by default tail calls weren't actually enabled. This commitrefactors handling of `Strategy` to avoid storing `Strategy::Auto` in`CompilerConfig` so tests against it can use either cranelift or winch.* Update disas tests* Update Winch tests to using winch List of files: /wasmtime-44.0.1/tests/all/module.rs

24c1388c - Call-indirect caching: protect against out-of-bounds table index during prescan. (#8541)

Fri, 03 May 2024 20:14:50 +0000

Call-indirect caching: protect against out-of-bounds table index during prescan. (#8541)* Call-indirect caching: protect against out-of-bounds table index during prescan.Call-indirect caching requires a "prescan" of a module's code sectionduring compilation in order to know which tables are possibly written,and to count call-indirect callsites so that each separate functioncompilation can enable caching if possible and use the right slotrange.This prescan is not integrated with the usual validation logic (norshould it be, probably, for performance), so it's possible that anout-of-bounds table index or other illegal instruction could bepresent. We previously indexed into an internal datastructure (`table_plans`) with this index, allowing for a compilationpanic on certain invalid modules before validation would have caughtit. This PR fixes that with a one-off check at the single point thatwe interpret a parameter (the table index) from an instruction duringthe prescan.* Add test case. List of files: /wasmtime-44.0.1/tests/all/module.rs

c607704c - Fix combining `cache_call_indirects` and memory64 (#8544)

Fri, 03 May 2024 19:03:18 +0000

Fix combining `cache_call_indirects` and memory64 (#8544)This commit fixes a fuzz bug that popped up where the`cache_call_indirects` feature wasn't reading memory64-based offsetscorrectly. This is due to (not great) API design in `wasmparser`(introduced by me) where wasmparser by default won't read 64-bit offsetsunless explicitly allowed to. This is to handle how spec tests assertthat overlong 32-bit encodings are invalid as the memory64 proposalisn't merged into the spec yet.The fix here is to call `allow_memarg64` with whether memory64 isenabled or not and then that'll enable reading these overlong and/orlarger offsets correctly. List of files: /wasmtime-44.0.1/tests/all/module.rs

3594cc96 - Slightly improve error message of feeding components to `Module` APIs (#8235)

Mon, 25 Mar 2024 20:19:42 +0000

Slightly improve error message of feeding components to `Module` APIs (#8235)This commit slightly improves the error message of feeding a componentinto a module-taking API. This at least tries to convey that a componentwas recognized but a module was expected. List of files: /wasmtime-44.0.1/tests/all/module.rs

9ce3ffe1 - Update some CI dependencies (#7983)

Thu, 22 Feb 2024 23:54:03 +0000

Update some CI dependencies (#7983)* Update some CI dependencies* Update to the latest nightly toolchain* Update mdbook* Update QEMU for cross-compiled testing* Update `cargo nextest` for usage with MIRIprtest:full* Remove lots of unnecessary imports* Downgrade qemu as 8.2.1 seems to segfault* Remove more imports* Remove unused winch trait method* Fix warnings about unused trait methods* More unused imports* More unused imports List of files: /wasmtime-44.0.1/tests/all/module.rs