en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wizer/src/component/parse.rs#228f448b Migrate Wizer to `wasmtime::error` (#12266) List of files: /wasmtime-44.0.1/crates/wizer/src/component/parse.rs Wed, 07 Jan 2026 22:07:34 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wizer/src/component/parse.rs#155f8276 wizer: Partially support nested components (#11898)* wizer: Partially support nested componentsSupport nested components insofar as they don't have access to modulesat this time. This helps `wasmtime wizer` support wasm-tools-generatedcomponents which use nested components for type-ascribing exports.Otherwise though nested components are not allowed to defined orinstantiate core modules as that would need more implementation in Wizerto support.* Two-level test too* Add test.wasm to wizer's gitignore* Fix test List of files: /wasmtime-44.0.1/crates/wizer/src/component/parse.rs Tue, 21 Oct 2025 20:37:17 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wizer/src/component/parse.rs#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/src/component/parse.rs Mon, 20 Oct 2025 17:55:39 +0000 Alex Crichton <alex@alexcrichton.com>