en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wizer/#228f448b Migrate Wizer to `wasmtime::error` (#12266) List of files: /wasmtime-44.0.1/crates/wizer/src/component.rs Wed, 07 Jan 2026 22:00:00 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wizer/#e6937050 only remove `_initialize` function from module snapshots (#12540)* only remove `_initialize` function from module snapshotsRemoving `_initialize` from snapshots of wit-component-produced components leadsto invalid inputs because it breaks the alias `wit-component` creates.Moreover, removing that function is redundant because it is only called from astart function which is also removed during snapshotting.Ideally, removing `_initialize` and any aliases which point to it would be takencare of a general-purpose component dead code removal tool, but no such toolexists yet. In the meantime, leaving it there creates a bit of code bloat butis otherwise harmless.* add wizer test for `_initialize` in components List of files: /wasmtime-44.0.1/crates/wizer/src/lib.rs/wasmtime-44.0.1/crates/wizer/tests/all/component.rs Mon, 09 Feb 2026 17:00:00 +0000 Joel Dice <joel.dice@fermyon.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wizer/#278656ce Merge component-init into wasmtime-wizer (#11878)* Merge component-init into wasmtime-wizerThis commit is the next phase of merging the wizer and component-initrepositories into Wasmtime. This does not take the same approach asmerging wizer where the git histories were merged, but instead thistakes an entirely different approach for component-init. Effectively Iread the code in component-init and copied over the spirit of the codeinto the wasmtime-wizer crate. Very little was literally copied over dueto such large changes in the internals of organization andimplementation. The main goal of merging this repository is to replacethe core wasm tracking of state in component-init with whatwasmtime-wizer already has. Sort of like the runtime in the `wasmtime`crate the goal is to build component support entirely on top of coresupport to avoid duplicating anything.The general strategy for pre-init components is that unlike core wasmwhere more exports are added a component has a new module and newaccessor functions injected for all state found in the component. Forexample an `i32` global results in a `(func (result s32))` in WIT.Memories result in `(func (result (list u8)))`. This "accessor module"is synthetically built during the instrumentation pass of Wizer and thenused to acquire snapshot results afterwards.All of this support is added in a new `component` submodule of the`wasmtime-wizer` crate. This submodule has the same structure as itscore wasm counterpart at the root of the crate, but the internalimplementations are entirely different. Anything encountering a corewasm module delegates to the core wasm support in the root of the cratefor Wizer.There is one new limitation at this time over what component-initsupports which is that nested components are not supported just yet.Currently in component-init nested components are copied over as-iswhich ends up producing a faulty initialization if the componentsactually have core wasm instances associated with them. For now thisimplementation sidesteps this by forbidding nested components entirely.To support wizening the output of `wasm-tools component {new,link}`,however, some support for nested components will be required. I plan onadding that in a follow-up commit.Testing of component-init is pretty light right now so this commitcopies over a few `*.wat` tests "in spirit" but does not literally copyover the preexisting tests. There are a few tests in component-initwhich initialize the real output of `wasm-tools component new` which maywant to be migrated eventually but my hope is that this repo can stickto smaller more focused tests for now.One large-ish change made to `wasmtime-wizer` during this merge was tochange snapshotting functionality to being an `async` function. This isrequired for components because reading state requires invoking afunction, which in the context of the `wasmtime run` subcommand isalways done in "async mode". This meant that the `async` propagatesoutwards to much of `wasmtime-wizer`, even the core wasm traits. My hopeis that this isn't a big issue as the CLI can deal with it and embedderscan throw an `async` in there.Overall this is intended to be a mostly-complete skeleton plus basicfunctionality for component-init. I have not done thorough testing withreal-world components just yet (e.g. componentize-py) so there willlikely be follow-up PRs to address various inevitable shortcomings I'veintroduced in this merge.* Deduplicate some debug asserts* Fix wizer benches/fuzzing* Use `wizer-initialize` for core wasm and components* Only copy out nonzero contents of memory, not all memory* Fix a rebase conflict* Revert "Only copy out nonzero contents of memory, not all memory"This reverts commit 865146cc459826945cd22f4a41f1137d3e8c1c46. List of files: /wasmtime-44.0.1/crates/wizer/tests/regex-test/src/lib.rs Mon, 20 Oct 2025 17:00:00 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wizer/#cc8d04f4 Remove need for explicit `Config::async_support` knob (#12371)* Refactor component model host function definitionsPush the `async`-ness down one layer.* Remove need for explicit `Config::async_support` knobThis commit is an attempt to step towards reconciling "old async" and"new async" in Wasmtime. The old async style is the original asyncsupport in Wasmtime with `call_async`, `func_wrap_async`, etc, where themain property is that the store is "locked" during an async operation.Put another way, a store can only execute at most one async operation ata time. This is in contrast to "new async" support in Wasmtime with thecomponent-model-async (WASIp3) support, where stores can have more thanone async operation in flight at once.This commit does not fully reconcile these differences, but it doesremove one hurdle along the way: `Config::async_support`. Since thebeginning of Wasmtime this configuration knob has existed to explicitlydemarcate a config/engine/store as "this thing requires `async` stuffinternally." This has started to make less and less sense over timewhere the line between sync and async has become more murky with WASIp3where the two worlds comingle. The goal of this commit is to deprecate`Config::async_support` and make the function not actually do anything.In isolation this can't simply be done, however, because there are manyload-bearing aspects of Wasmtime that rely on this `async_support` knob.For example once epochs + yielding are enabled it's required that allWasm is executed on a fiber lest it hit an epoch and not know how toyield. That means that this commit is not a simple removal of`async_support` but instead a refactoring/rearchitecting of how async isused internally within Wasmtime. The high-level ideas within Wasmtimenow are:* A `Store` has a "requires async" boolean stored within it.* All configuration options which end up requiring async, such as yielding with epochs, turn this boolean on.* Creation of host functions which use async (e.g. `func_wrap_{async,concurrent}`) will also turn this option on.* Synchronous API entrypoints into Wasmtime ensure that this boolean is disabled.* Asynchronous APIs are usable at any time.This means that the concept of an async store vs a sync store is nowgone. All stores are equally capable of executing sync/async, and thechange now is that dynamically some stores will require that async isused with certain configuration. Additionally all panicking conditionsaround `async_support` have been converted to errors instead. Allrelevant APIs already returned an error and things are murky enough nowthat it's not necessarily trivial to get this right at the embedderlevel. In the interest of avoiding panics all detected async mismatchesare now first-class `wasmtime::Error` values.The end result of this commit is that `Config::async_support` is adeprecated `#[doc(hidden)]` function that does nothing. While manyinternal changes happened as well as having new tests for all this sortof behavior this is not expected to have a great impact on externalconsumers. In general a deletion of `async_support(true)` is in theoryall that's required. This is intended to make it easier to think aboutasync/sync/etc in the future with WASIp3 and eventually reconcile`func_wrap_async` and `func_wrap_concurrent` for example. That's leftfor future refactorings however.prtest:full* Review comments* Fix CI failures List of files: /wasmtime-44.0.1/crates/wizer/tests/all/tests.rs Fri, 23 Jan 2026 02:00:00 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wizer/#18aff9aa Integrate wizer into this repository (#11805)* Remove misc wizer-related files* Integrate the Wizer manifest with this repo's workspace* Enable some more wasmtime features* Get wizer tests passing in-repo* Remove duplicate dummy wizer module* Integer `wasmtime wizer` subcommand into the CLI* Fully integrate wizer into `wasmtime` CLI* Split `wasmtime run` into helper functions* Split `Wizer::run` into helper functions* Weave the two together in `wasmtime wizer`The end goal is to have all CLI options in `wasmtime run` applicable for`wasmtime wizer` as well with some light edits between the two. Overallthough we shouldn't have to proactively support commands in one or theother and everything ideally should "just work".* Fix clippy warnings and bench compiles* Fix benchmarks* Create a store-per-iteration* Use the right wasms in the regex benchmark* Get wizer fuzzer building again* Get CLI working again* Run rustfmt* Remove precompiled wasms from the tree35M for some wasms is a bit heavy so instead build them from source.* Update vet configuration for fuzzers/tests* Update publish script with wasmtime-wizer* Fix clippy lint* Some docs and more clippy lintsprtest:full* Relax version requirement* Try to fix asan build* Remove rustflags too* Un-exclude wizer* Adjust publish script* Update lock file after rebase* Integrate bytecodealliance/wizer#139Use deterministic results for relaxed simd operations by default.* Handle preloads in wizer* Appease clippy* Use deterministic relaxed simd in wizer tests List of files: /wasmtime-44.0.1/crates/wizer/tests/regex-test/Cargo.toml Mon, 13 Oct 2025 19:00:00 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wizer/#f80bd028 Allow WASI to be used during initialization List of files: /wasmtime-44.0.1/crates/wizer/tests/regex-test/README.md Fri, 20 Nov 2020 00:00:00 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wizer/#c3a6060b Polyfill `ToWasmtimeResult` and add eventually-necessary call sites (#12308)* Polyfill `ToWasmtimeResult` and add eventually-necessary call sitesThis commit polyfills `wasmtime_internal_error::ToWasmtimeResult` in`wasmtime_environ`, adds the cargo feature plumbing that will eventually connectto the `"wasmtime_internal_error/anyhow"` cargo feature but for now justconfigures this polyfill, and adds uses of the polyfill at all the sites thatwill be necessary once we swap out `anyhow` for`wasmtime_internal_error`. Currently, the polyfill is just an identity function,because `wasmtime::Result`/`wasmtime_environ::error::Result` is just anothername for `anyhow::Result`. Once we do move away from `anyhow`, however, thatwill no longer be the case, and these uses will do the necessary conversion.My goal with landing this as an incremental commit is to make it so that theactual commit that does the error crate swap out can be as close to _just_ the`Cargo.toml` dependency change, without any other code changes as much aspossible. This, in turn, means that swap out should be super easy to revert, ifnecessary.* Add a couple more `.to_wasmtime_result()` invocations in fuzz code* Revert "Add a couple more `.to_wasmtime_result()` invocations in fuzz code"This reverts commit b33696e5f63f7eed731ca9dad10fec5e55a550d3.* Move cranelift fuzz targets back to anyhow* Fix cargo feature enablement for explorer List of files: /wasmtime-44.0.1/crates/wizer/Cargo.toml Tue, 13 Jan 2026 18:00:00 +0000 Nick Fitzgerald <fitzgen@gmail.com>