Changes in module.rs

dc029724 - Migrate C API to `wasmtime::error` (#12259)

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

Migrate C API to `wasmtime::error` (#12259) List of files: /wasmtime-44.0.1/crates/c-api/src/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/crates/c-api/src/module.rs

ae84e6ed - Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)

Thu, 09 Jan 2025 21:05:55 +0000

Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)* Enable `unsafe-attr-outside-unsafe` 2024 edition lintThis commit enables the `unsafe-attr-outside-unsafe` lint in rustc usedin transitioning to the 2024 edition. This requires that the`#[no_mangle]` attribute is replaced in favor of `#[unsafe(no_mangle)]`.This mostly affects the C API of wasmtime and most of the changes hereare a simple search/replace.* Another attribute update* Fix command adapter build List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

b7631976 - Add Cranelift and Winch features to the C API (#8661)

Mon, 20 May 2024 18:58:23 +0000

Add Cranelift and Winch features to the C API (#8661)* Add Cranelift and Winch features to the C APIThis commit adds `cranelift` and `winch` features to the C API andenables them by default. This means that the C API can now be builtwithout compiler support to only support loading precompiled binaries.Closes #7349* Fix doc link* More doc fixes* Add more doc input dirs List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

120e6b23 - Add Component::image_range (#7939)

Wed, 14 Feb 2024 20:23:23 +0000

Add Component::image_range (#7939)* Add Component::image_rangeThis is the same as `Module::image_range` but for components. While I'mhere additionally return a pointer instead of a `usize` to furtheremphasize that it's in the host's address space.* Remove unused import* Fix compilation of the C API List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

8652011f - Refactor `wasmtime::FuncType` to hold a handle to its registered type (#7892)

Fri, 09 Feb 2024 21:07:52 +0000

Refactor `wasmtime::FuncType` to hold a handle to its registered type (#7892)* Refactor `wasmtime::FuncType` to hold a handle to its registered typeRather than holding a copy of the type directly, it now holds a `RegisteredType`which internally is* A `VMSharedTypeIndex` pointing into the engine's types registry.* An `Arc` handle to the engine's type registry.* An `Arc` handle to the actual type.The last exists only to keep it so that accessing a `wasmtime::FuncType`'sparameters and results fast, avoiding any new locking on call hot paths.This is helping set the stage for further types and `TypeRegistry` refactorsneeded for Wasm GC.* Update the C API for the function types refactorprtest:full* rustfmt* Fix benches build List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

2d43a28f - c-api: Expose image_range for modules (#7064)

Wed, 20 Sep 2023 14:35:40 +0000

c-api: Expose image_range for modules (#7064)We're using this to monitor the amount of executable memory each moduleneeds.Signed-off-by: Tyler Rockwood List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

1d319c0e - c-api: refactor definitions with macroes (#4416)

Mon, 11 Jul 2022 14:10:41 +0000

c-api: refactor definitions with macroes (#4416)Signed-off-by: spacewander List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

13ec5ff6 - c-api: Add a way to get type of `wasmtime_module_t` (#3959)

Thu, 24 Mar 2022 18:32:56 +0000

c-api: Add a way to get type of `wasmtime_module_t` (#3959)My previous PR at #3958 accidentally removed the only way to get type information from a `wasmtime_module_t`, so this commit re-adds methods back in to continue to be able to get import/export information from a compiled module. List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

76b82910 - Remove the module linking implementation in Wasmtime (#3958)

Wed, 23 Mar 2022 19:57:34 +0000

Remove the module linking implementation in Wasmtime (#3958)* Remove the module linking implementation in Wasmtime This commit removes the experimental implementation of the module linking WebAssembly proposal from Wasmtime. The module linking is no longer intended for core WebAssembly but is instead incorporated into the component model now at this point. This means that very large parts of Wasmtime's implementation of module linking are no longer applicable and would change greatly with an implementation of the component model. The main purpose of this is to remove Wasmtime's reliance on the support for module-linking in `wasmparser` and tooling crates. With this reliance removed we can move over to the `component-model` branch of `wasmparser` and use the updated support for the component model. Additionally given the trajectory of the component model proposal the embedding API of Wasmtime will not look like what it looks like today for WebAssembly. For example the core wasm `Instance` will not change and instead a `Component` is likely to be added instead. Some more rationale for this is in #3941, but the basic idea is that I feel that it's not going to be viable to develop support for the component model on a non-`main` branch of Wasmtime. Additionaly I don't think it's viable, for the same reasons as `wasm-tools`, to support the old module linking proposal and the new component model at the same time. This commit takes a moment to not only delete the existing module linking implementation but some abstractions are also simplified. For example module serialization is a bit simpler that there's only one module. Additionally instantiation is much simpler since the only initializer we have to deal with are imports and nothing else. Closes #3941 * Fix doc link * Update comments List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

9e0c9100 - Add a `Module::deserialize_file` method (#3266)

Tue, 31 Aug 2021 18:05:51 +0000

Add a `Module::deserialize_file` method (#3266)* Add a `Module::deserialize_file` method This commit adds a new method to the `wasmtime::Module` type, `deserialize_file`. This is intended to be the same as the `deserialize` method except for the serialized module is present as an on-disk file. This enables Wasmtime to internally use `mmap` to avoid copying bytes around and generally makes loading a module much faster. A C API is added in this commit as well for various bindings to use this accelerated path now as well. Another option perhaps for a Rust-based API is to have an API taking a `File` itself to allow for a custom file descriptor in one way or another, but for now that's left for a possible future refactoring if we find a use case. * Fix compat with main - handle readdonly mmap * wip * Try to fix Windows support List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

7a1b7cdf - Implement RFC 11: Redesigning Wasmtime's APIs (#2897)

Thu, 03 Jun 2021 14:10:53 +0000

Implement RFC 11: Redesigning Wasmtime's APIs (#2897)Implement Wasmtime's new API as designed by RFC 11. This is quite a large commit which has had lots of discussion externally, so for more information it's best to read the RFC thread and the PR thread. List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

8384f3a3 - Bring back `Module::deserialize` (#2858)

Tue, 27 Apr 2021 15:55:12 +0000

Bring back `Module::deserialize` (#2858)* Bring back `Module::deserialize` I thought I was being clever suggesting that `Module::deserialize` was removed from #2791 by funneling all module constructors into `Module::new`. As our studious fuzzers have found, though, this means that `Module::new` is not safe currently to pass arbitrary user-defined input into. Now one might pretty reasonable expect to be able to do that, however, being a WebAssembly engine and all. This PR as a result separates the `deserialize` part of `Module::new` back into `Module::deserialize`. This means that binary blobs created with `Module::serialize` and `Engine::precompile_module` will need to be passed to `Module::deserialize` to "rehydrate" them back into a `Module`. This restores the property that it should be safe to pass arbitrary input to `Module::new` since it's always expected to be a wasm module. This also means that fuzzing will no longer attempt to fuzz `Module::deserialize` which isn't something we want to do anyway. * Fix an example * Mark `Module::deserialize` as `unsafe` List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

d1313b12 - Code review feedback.

Thu, 01 Apr 2021 06:46:30 +0000

Code review feedback.* Move `Module::compile` to `Engine::precompile_module`.* Remove `Module::deserialize` method.* Make `Module::serialize` the same format as `Engine::precompile_module`.* Make `Engine::precompile_module` return a `Vec`.* Move the remaining serialization-related code to `serialization.rs`. List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

41caf67a - Update the C API with module linking support (#2472)

Thu, 03 Dec 2020 21:51:38 +0000

Update the C API with module linking support (#2472)* Update the C API with module linking support This commit does everything necessary (ideally) to support the module linking proposal in the C API. The changes here are: * New `wasm_{module,instance}type_t` types and accessors * New `wasm_{module,instance}_type` functions * Conversions between `wasm_extern_t` and `wasm_{instance,module}_t`, as well as `wasm_externtype_t` and the new types. * Addition of `WASM_EXTERN_{MODULE,INSTANCE}` constants * New `wasm_config_t` modifier to enable/disable module linking With these functions it should be possible to pass instances/modules to instances and also acquire them from exports. Altogether this should enable everything for module linking. An important point for this is that I've opted to add all these items under the `wasm_*` name prefix instead of `wasmtime_*`. I've done this since they're all following the idioms of existing APIs and while not standard the intention would be to standardize them (unlike many other Wasmtime-specific APIs). cc #2094 * Appease doxygen List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

62be6841 - Propagate optional import names to the wasmtime/C API

Mon, 23 Nov 2020 23:17:34 +0000

Propagate optional import names to the wasmtime/C APIWith the module linking proposal the field name on imports is nowoptional, and only the module is required to be specified. This commitpropagates this API change to the boundary of wasmtime's API, ensuringconsumers are aware of what's optional with module linking and whatisn't. Note that it's expected that all existing users will eitherupdate accordingly or unwrap the result since module linking ispresumably disabled. List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

399ee0a5 - Serialize and deserialize compilation artifacts. (#2020)

Tue, 21 Jul 2020 20:05:50 +0000

Serialize and deserialize compilation artifacts. (#2020)* Serialize and deserialize Module * Use bincode to serialize * Add wasm_module_serialize; docs * Simple tests List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

a817470f - Fix signature of wasmtime_module_new

Wed, 15 Jul 2020 19:07:36 +0000

Fix signature of wasmtime_module_new List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

cca558cd - Remove `HostRef` from the C API (#1926)

Fri, 26 Jun 2020 19:34:34 +0000

Remove `HostRef` from the C API (#1926)This commit removes `HostRef` from the C API which only served the purpose now of converting each type to a `wasm_ref_t*`. Our implementation, however, does not guarantee that you'll get the same `wasm_ref_t*` for each actual underlying item (e.g. if you put a func in a table and then get the func as an export and from the table then `same` will report `false`). Additionally the fate of `wasm_ref_t*` seems somewhat unclear at this point. The change here is to make the `same` and cast functions all abort saying they're unimplemented. (similar to the host info functions). If and when we get around to reimplementing these functions we can ensure they're implemented uniformly and work well for all intended use cases. List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs

e40c039e - wasmtime: Rip out incomplete/incorrect externref "host info" support

Thu, 25 Jun 2020 17:24:40 +0000

wasmtime: Rip out incomplete/incorrect externref "host info" supportBetter to be loud that we don't support attaching arbitrary host info to`externref`s than to limp along and pretend we do support it. Supporting itproperly won't reuse any of this code anyways. List of files: /wasmtime-44.0.1/crates/c-api/src/module.rs