Changes in module_types.rs

cd2cba7a - Rename our OOM-handling `SecondaryMap` to `TrySecondaryMap` (#12727)

Mon, 09 Mar 2026 18:19:16 +0000

Rename our OOM-handling `SecondaryMap` to `TrySecondaryMap` (#12727) List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

44224d56 - Rename our OOM-handling `PrimaryMap` to `TryPrimaryMap` (#12726)

Mon, 09 Mar 2026 17:34:37 +0000

Rename our OOM-handling `PrimaryMap` to `TryPrimaryMap` (#12726) List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

e8a25f5b - Use OOM-handling `{Primary,Secondary}Map` in `wasmtime_environ::ModuleTypes` (#12622)

Wed, 25 Feb 2026 16:36:47 +0000

Use OOM-handling `{Primary,Secondary}Map` in `wasmtime_environ::ModuleTypes` (#12622) List of files: /wasmtime-44.0.1/crates/environ/src/module_types.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/environ/src/module_types.rs

cb235ecf - Wasm GC: Fix an incorrect assertion and canonicalize types for runtime usage in ExternType::from_wasmtime (#10223)

Fri, 14 Feb 2025 17:03:26 +0000

Wasm GC: Fix an incorrect assertion and canonicalize types for runtime usage in ExternType::from_wasmtime (#10223)* Fix assertion in `PartialEq` for `RegisteredType` againIt is possible for two `WasmSubType`s to be equal to each other, as far as`derive(PartialEq)` is concerned, but still different from each other if theyare in different rec groups or even if they are at different indices within thesame rec group. The assertion mistakenly did not permit either of these,however.Fixes #9714* Canonicalize all types for runtime usage when creating `wasmtime::{Module,Component}`sRather than canonicalizing them on demand in functions like`{Func,Global,Table}Type::from_wasmtime` and other places. Instead, we do it inone place, up front, so that it is very unlikely we miss anything. Doing thisinvolves changing some things from `ModuleInternedTypeIndex`es to`EngineOrModuleTypeIndex`es in `wasmtime_environ`, which means that a bunch ofuses of those things need to unwrap the appropriate kind of type index at usagesites (e.g. compilation uses will unwrap `ModuleInternedTypeIndex`es, runtimeuses usage will unwrap `VMSharedTypeIndex`es). And it additionally requiredimplementing the `TypeTrace` trait for a handful of things to unlock theprovided `canonicalize_for_runtime_usage` trait method for those things.All this machinery is required to avoid an assertion failure in the regressiontest introduced in the previous commit, which was triggered because we werefailing to canonicalize type indices inside `ExternType`s for runtime usage onsome code paths. We shouldn't have to play that kind of whack-a-mole in thefuture, thanks to this new approach.* Fix a warning in no-default-features builds* Fix another warning in weird cfg builds List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

de1ad347 - Enable `impl-trait-overcaptures` 2024 transition lint (#9965)

Thu, 09 Jan 2025 23:13:22 +0000

Enable `impl-trait-overcaptures` 2024 transition lint (#9965)* Enable `impl-trait-overcaptures` 2024 transition lintThis lint detects cases where returning `impl Trait` will workdifferently in 2024 than in the current 2021 edition. Ambiguities areresolved with `use<..>` syntax stabilized in Rust 1.82.0 to mean thesame thing in both editions.* Fix some more `impl Trait` returns* Tighten bounds on settings `iter`* Fix build on 1.82.0* Fix another capture on MSRV List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

01462609 - Enable some miscellaneous Wasm GC spec tests; fix module import/export linking and subtyping (#9446)

Thu, 10 Oct 2024 17:41:39 +0000

Enable some miscellaneous Wasm GC spec tests; fix module import/export linking and subtyping (#9446)* Enable some miscellaneous GC spec testsThese weren't caught by our checks that `should_fail` tests do not pass, I thinkbecause they only contain modules that should validate, and not any actualassertions.* Require declared subtyping when linking module import/export functionsWe were previously incorrectly doing a (shallow) match on structure when weshould have been doing a subtyping check. List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

a0704a89 - Merge `wasmtime-types` into `wasmtime-environ` (#9342)

Wed, 02 Oct 2024 00:13:41 +0000

Merge `wasmtime-types` into `wasmtime-environ` (#9342)The only reason that this was originally split out was because`cranelift-wasm` depended on `wasmtime-types`. Now that `cranelift-wasm`has been merged into `wasmtime-cranelift` there's no need any longer tomaintain this split. This commit merges the `wasmtime-types` crate backinto `wasmtime-environ`. List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

0e9121da - Fix some typos (#8641)

Thu, 16 May 2024 23:21:22 +0000

Fix some typos (#8641)* occurred* winch typos* tests typos* cli typos* fuzz typos* examples typos* docs typos* crates/wasmtime typos* crates/environ typos* crates/cranelift typos* crates/test-programs typos* crates/c-api typos* crates/cache typos* crates other typos* cranelift/codegen/src/isa typos* cranelift/codegen/src other typos* cranelift/codegen other typos* cranelift other typos* ci js typo* .github workflows typo* RELEASES typo* Fix clang-format documentation line---------Co-authored-by: Andrew Brown List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

a9473409 - wasmtime(gc): Fix wasm-to-native trampoline lookup for subtyping (#8579)

Wed, 08 May 2024 16:31:12 +0000

wasmtime(gc): Fix wasm-to-native trampoline lookup for subtyping (#8579)* wasmtime(gc): Fix wasm-to-native trampoline lookup for subtypingPreviously, we would look up a wasm-to-native trampoline in the Wasm modulebased on the host function's type. With Wasm GC and subtyping, this becomesproblematic because a Wasm module can import a function of type `T` but the hostcan define a function of type `U` where `U <: T`. And if the Wasm has neverdefined type `U` then it wouldn't have a trampoline for it. But our trampolinesdon't actually care, they treat all reference values within the same typehierarchy identically. So the trampoline for `T` would have worked inpractice. But once we find a trampoline for a function, we cache it and reuse itevery time that function is used in the same store again. Even if the functionis imported with its precise type somewhere else. So then we would have atrampoline of the wrong type. But this happened to be okay in practice becausethe trampolines happen not to inspect their arguments or do anything with themother than forward them between calling convention locations. But relying onthat accidental invariant seems fragile and like a gun aimed at the future'sfeet.This commit makes that invariant non-accidental, centering it and hopefullymaking it less fragile by doing so, by making every function type have anassociated "trampoline type". A trampoline type is the original function typebut where all the reference types in its params and results are replaced withthe nullable top versions, e.g. `(ref $my_struct)` is replaced with `(ref nullany)`. Often a function type is its own associated trampoline type, as is thecase for all functions that don't have take or return any references, forexample. Then, all trampoline lookup begins by first getting the trampoline typeof the actual function type, or actual import type, and then only afterwardsfinding for the pre-compiled trampoline in the Wasm module.Fixes https://github.com/bytecodealliance/wasmtime/issues/8432Co-Authored-By: Jamey Sharp * Fix no-std build---------Co-authored-by: Jamey Sharp List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

c810eff8 - Migrate the `wasmtime-environ` crate to `no_std` (#8528)

Thu, 02 May 2024 23:29:55 +0000

Migrate the `wasmtime-environ` crate to `no_std` (#8528)* Migrate the `wasmtime-environ` crate to `no_std`This commit migrates the `wasmtime-environ` crate to by default beingtagged with `#![no_std]`. Only the `component-model` and `gc` featuresare able to be built without `std`, all other features will implicitlyactivate the `std` feature as they currently require it one way oranother. CI is updated to build `wasmtime-environ` with these twofeatures active on a no_std platform.This additionally, for the workspace, disables the `std` feature for the`target-lexicon`, `indexmap`, `object`, and `gimli` dependencies. Forobject/gimli all other crates in the workspace now enable the `std`feature, but for `wasmtime-environ` this activation is omitted.The `thiserror` dependency was dropped from `wasmtime-environ` andadditionally `hashbrown` was added for explicit usage of maps.* Always enable `std` for environ for nowprtest:full* Add some more std features List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

dd70e31d - wasmtime(gc): Add support for array types (#8481)

Fri, 26 Apr 2024 16:44:31 +0000

wasmtime(gc): Add support for array types (#8481)This commit adds support for defining array types from Wasm or the host, andmanaging them inside the engine's types registry. It does not introduce supportfor allocating or manipulating array values. That functionality will come infuture pull requests. List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

c1730b2b - Gate type-builder types from `wasmtime-environ` on `compile` (#8484)

Fri, 26 Apr 2024 14:12:38 +0000

Gate type-builder types from `wasmtime-environ` on `compile` (#8484)* Gate type-builder types from `wasmtime-environ` on `compile`This commit gates the `*Builder` types related to building sets of typesin the `wasmtime-environ` crate on the `compile` feature. This helpsbring in less code when the feature is disabled and helps exclude somedependencies for the upcoming `no_std` migration as well.This commit doesn't change anything, it's just moving code around.* Remove no-longer-needed importprtest:full List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

960187e3 - Rename `Concrete` to `ConcreteFunc`; introduce `WasmSubType` and `WasmCompositeType` (#8465)

Wed, 24 Apr 2024 21:22:47 +0000

Rename `Concrete` to `ConcreteFunc`; introduce `WasmSubType` and `WasmCompositeType` (#8465)* Rename `WasmHeapType::Concrete(_)` to `WasmHeapType::ConcreteFunc(_)`* Rename `wasmtime::HeapType::Concrete` to `wasmtime::HeapType::ConcreteFunc`* Introduce Wasm sub- and composite-typesRight now, these are only ever final function types that don't have a supertype,but this refactoring paves the way for array and struct types, and lets us makesure that `match`es are exhaustive for when we add new enum variants. (AlthoughI did add an `unwrap_func` helper for use when it is clear that the type shouldbe a function type, and if it isn't then we should panic.) List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

1c013e30 - Add support for recursion groups in the types registry (#8404)

Fri, 19 Apr 2024 16:35:57 +0000

Add support for recursion groups in the types registry (#8404) List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

ff93bce0 - Wasmtime: Finish support for the typed function references proposal (#7943)

Tue, 20 Feb 2024 20:33:28 +0000

Wasmtime: Finish support for the typed function references proposal (#7943)* Wasmtime: Finish support for the typed function references proposalWhile we supported the function references proposal inside Wasm, we didn'tsupport it on the "outside" in the Wasmtime embedder APIs. So much of the workhere is exposing typed function references, and their type system updates, inthe embedder API. These changes include:* `ValType::FuncRef` and `ValType::ExternRef` are gone, replaced with the introduction of the `RefType` and `HeapType` types and a `ValType::Ref(RefType)` variant.* `ValType` and `FuncType` no longer implement `Eq` and `PartialEq`. Instead there are `ValType::matches` and `FuncType::matches` methods which check directional subtyping. I also added `ValType::eq` and `FuncType::eq` static methods for the rare case where someone needs to check precise equality, but that is almost never actually the case, 99.99% of the time you want to check subtyping.* There are also public `Val::matches_ty` predicates for checking if a value is an instance of a type, as well as internal helpers like `Val::ensure_matches_ty` that return a formatted error if the value does not match the given type. These helpers are used throughout Wasmtime internals now.* There is now a dedicated `wasmtime::Ref` type that represents reference values. Table operations have been updated to take and return `Ref`s rather than `Val`s.Furthermore, this commit also includes type registry changes to correctly managelifetimes of types that reference other types. This wasn't previously an issuebecause the only thing that could reference types that reference other types wasa Wasm module that added all the types that could reference each other at thesame time and removed them all at the same time. But now that the previouslydiscussed work to expose these things in the embedder API is done, type lifetimemanagement in the registry becomes a little trickier because the embedder mightgrab a reference to a type that references another type, and then unload theWasm module that originally defined that type, but then the user should still beable use that type and the other types it transtively references. Before, wewere refcounting individual registry entries. Now, we still are refcountingindividual entries, but now we are also accounting for type-to-type referencesand adding a new type to the registry will increment the refcounts of each ofthe types that it references, and removing a type from the registry willdecrement the refcounts of each of the types it references, and then recursively(logically, not literally) remove any types whose refcount has now reached zero.Additionally, this PR adds support for subtyping to `Func::typed`- and`Func::wrap`-style APIs. For result types, you can always use a supertype of theWebAssembly function's actual declared return type in `Func::typed`. And forparam types, you can always use a subtype of the Wasm function's actual declaredparam type. Doing these things essentially erases information but is alwayscorrect. But additionally, for functions which take a reference to a concretetype as a parameter, you can also use the concrete type's supertype. Consider aWebAssembly function that takes a reference to a function with a concrete type:`(ref null )`. In this scenario, there is no static`wasmtime::Foo` Rust type that corresponds to that particular Wasm-definedconcrete reference type because Wasm modules are loaded dynamically atruntime. You *could* do `f.typed::, ()>()`, and while that iscorrectly typed and valid, it is often overly restrictive. The only value youcould call the resulting typed function with is the null function reference, butwe'd like to call it with non-null function references that happen to be of thecorrect type. Therefore, `f.typed, ()>()` is also allowed in thiscase, even though `Option` represents `(ref null func)` which is thesupertype, not subtype, of `(ref null )`. This does imply someminimal dynamic type checks in this case, but it is supported for betterergonomics, to enable passing non-null references into the function.We can investigate whether it is possible to use generic type parameters andcombinators to define Rust types that precisely match concrete reference typesin future, follow-up pull requests. But for now, we've made things usable, atleast.Finally, this also takes the first baby step towards adding support for the WasmGC proposal. Right now the only thing that is supported is `nofunc` references,and this was mainly to make testing function reference subtyping easier. Butthat does mean that supporting `nofunc` references entailed also adding a`wasmtime::NoFunc` type as well as the `Config::wasm_gc(enabled)` knob. So weofficially have an in-progress implementation of Wasm GC in Wasmtime after thisPR lands!Fixes https://github.com/bytecodealliance/wasmtime/issues/6455* Fix WAT in test to be valid* Check that dependent features are enabled for function-references and GC* Remove unnecessary engine parameters from a few methodsEver since `FuncType`'s internal `RegisteredType` holds onto its own `Engine`,we don't need these anymore.Still useful to keep the `Engine` parameter around for the `ensure_matches`methods because that can be used to check correct store/engine usage forembedders.* Add missing dependent feature enabling for some tests* Remove copy-paste bit from test* match self to show it is uninhabited* Add a missing `is_v128` method* Short circuit a few func type comparisons* Turn comment into part of doc comment* Add test for `Global::new` and subtyping* Add tests for embedder API, tables, and subtyping* Add an embedder API test for setting globals and subtyping* Construct realloc's type from its index, rather than from scratch* Help LLVM better optimize our dynamic type checks in `TypedFunc::call_raw`* Fix call benchmark compilation* Change `WasmParams::into_abi` to take the whole func type instead of iter of params* Fix doc linksprtest:full* Fix size assertion on s390x List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

eff57321 - Rename `WasmHeapType::TypedFunc` to `WasmHeapType::Concrete` (#7901)

Thu, 08 Feb 2024 23:07:30 +0000

Rename `WasmHeapType::TypedFunc` to `WasmHeapType::Concrete` (#7901)Purely mechanical, not functional changes.This better matches the wording of the spec and of `wasmparser`, especially aswe prepare to implement Wasm GC, where there can be references to concrete typesthat are not functions (and are structs or arrays instead). List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

27d3ef2f - wasmtime: Rename `SignatureFooBar` to `TypeFooBar` (#7826)

Fri, 26 Jan 2024 23:38:59 +0000

wasmtime: Rename `SignatureFooBar` to `TypeFooBar` (#7826)* wasmtime: Rename `SignatureFooBar` to `TypeFooBar`No functional changes, just the following mechanical renames:* `VMSharedSignatureIndex` to `VMSharedTypeIndex`* `SignatureIndex` to `TypeIndex`* `SignatureRegistry` to `TypeRegistry`* and moreThis is intended to start paving the way for Wasm GC support, where there aremore than just function signatures in a Wasm module's type section, and we aregoing to need to register non-function-signature types in the registry as well,for things like casting between reference types and passing reference typesacross Wasm modules.* Reintroduce different index types for module-interned types vs Wasm-index-space types* Fix a couple unused-import warnings List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

ef07f40f - Update the wasm-tools family of crates (#7587)

Mon, 27 Nov 2023 18:32:03 +0000

Update the wasm-tools family of crates (#7587)This commit updates to the latest wasm-tools and `wit-bindgen` to bringthe family of crates forward. This update notably includes Nick's workon packed indices in the `wasmparser` crate for validation for theupcoming implementation of GC types. This meant that translation from`wasmparser` types to Wasmtime types now may work with a "type id"instead of just a type index which required plumbing not only Wasmtime'sown type information but additionally `wasmparser`'s type informationthroughout translation.This required a fair bit of refactoring to get this working but nochange in functionality is intended, only a different way of doingeverything prior. List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs

9ec02f9d - Decouple `serde` from its `derive` crate (#6917)

Tue, 29 Aug 2023 16:02:06 +0000

Decouple `serde` from its `derive` crate (#6917)By not activating the `derive` feature on `serde`, the compilation speedcan be improved by a lot. This is because `serde` can then compile inparallel to `serde_derive`, allowing it to finish compilation possiblyeven before `serde_derive`, unblocking all the crates waiting for`serde` to start compiling much sooner.As it turns out the main deciding factor for how long the compile time of aproject is, is primarly determined by the depth of dependencies ratherthan the width. In other words, a crate's compile times aren't affectedby how many crates it depends on, but rather by the longest chain ofdependencies that it needs to wait on. In many cases `serde` is part ofthat long chain, as it is part of a long chain if the `derive` featureis active:`proc-macro2` compile build script > `proc-macro2` run build script >`proc-macro2` > `quote` > `syn` > `serde_derive` > `serde` >`serde_json` (or any crate that depends on serde)By decoupling it from `serde_derive`, the chain is shortened and compiletimes get much better.Check this issue for a deeper elaboration:https://github.com/serde-rs/serde/issues/2584For `wasmtime` I'm seeing a reduction from 24.75s to 22.45s whencompiling in `release` mode. This is because wasmtime through `gimli`has a dependency on `indexmap` which can only start compiling when`serde` is finished, which you want to happen as early as possible sosome of wasmtime's dependencies can start compiling.To measure the full effect, the dependencies can't by themselvesactivate the `derive` feature. I've upstreamed a patch for`fxprof-processed-profile` which was the only dependency that activatedit for `wasmtime` (not yet published to crates.io). `wasmtime-cli` andco. may need patches for their dependencies to see a similarimprovement. List of files: /wasmtime-44.0.1/crates/environ/src/module_types.rs