Changes in module_artifacts.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_artifacts.rs

d42d0b6d - Use our OOM-handling `PrimaryMap` in the `wasmtime_environ::module_artifacts` module (#12623)

Wed, 25 Feb 2026 19:13:23 +0000

Use our OOM-handling `PrimaryMap` in the `wasmtime_environ::module_artifacts` module (#12623) List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

b298f375 - RR #2: Sha256 checksum for components (#12576)

Fri, 13 Feb 2026 21:11:58 +0000

RR #2: Sha256 checksum for components (#12576)* Add sha256 checksum for component for record/replay consistency* Move sha2 crate as workspace dependency* Run checksum digest only on recording configs* Fix CI error and restructure from_binary List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

17fbd3c6 - Debug: implement breakpoints and single-stepping. (#12133)

Fri, 12 Dec 2025 20:02:54 +0000

Debug: implement breakpoints and single-stepping. (#12133)* Debug: implement breakpoints and single-stepping.This is a PR that puts together a bunch of earlier pieces (patchablecalls in #12061 and #12101, private copies of code in #12051, and allthe prior debug event and instrumentation infrastructure) to implementbreakpoints in the guest debugger.These are implemented in the way we have planned in #11964: eachsequence point (location prior to a Wasm opcode) is now a patchable callinstruction, patched out (replaced with NOPs) by default. When patchedin, the breakpoint callsite calls a trampoline with the `patchable` ABIwhich then invokes the `breakpoint` hostcall. That hostcall emits thedebug event and nothing else.A few of the interesting bits in this PR include:- Implementations of "unpublish" (switch permissions back to read/write from read/execute) for mmap'd code memory on all our platforms.- Infrastructure in the frame-tables (debug info) metadata producer and parser to record "breakpoint patches".- A tweak to the NOP metadata packaged with the `MachBuffer` to allow multiple NOP sizes. This lets us use one 5-byte NOP on x86-64, for example (did you know x86-64 had these?!) rather than five 1-byte NOPs.This PR also implements single-stepping with a global-per-`Store` flag,because at this point why not; it's a small additional bit of logic todo *all* patches in all modules registered in the `Store` when that flagis enabled.A few realizations for future work:- The need for an introspection API available to a debugger to see the modules within a component is starting to become clear; either that, or the "module and PC" location identifier for a breakpoint switches to a "module or component" sum type. Right now, the tests for this feature use only core modules. Extending to components should not actually be hard at all, we just need to build the API for it.- The interaction between inlining and `patchable_call` is interesting: what happens if we inline a `patchable_call` at a `try_call` callsite? Right now, we do *not* update the `patchable_call` to a `try_call`, because there is no `patchable_try_call`; this is fine in the Wasmtime embedding in practice because we never (today!) throw exceptions from a breakpoint handler. This does suggest to me that maybe we should make patchability a property of any callsite, and allow try-calls to be patchable too (with the same restriction about no return values as the only restriction); but happy to discuss that one further.* Add missing debug.wat disas test.* Review feedback.* Fix comment on `CodeMemory::text_mut`.* Review feedback.* Review feedback: abort process on failure to re-apply executable permissions.* Implement icache flush for aarch64.This appears to be necessary as we otherwise see a failure in CI onmacOS/aarch64 that is consistent with patched-in breakpoint calls stillbeing incorrectly cached after we remove them and republish the code.There is a longstanding issue in #3310 tracking proper icache coherencehandling on aarch64. We implemented this for Linux with the `membarrier`syscall but never did so for macOS. Maybe this is the first point atwhich it matters, because code was always loaded at new addresses (hencedid not have coherence issues because nothing would have been cached)previously.prtest:full* Review feedback: use `next_multiple_of`. List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

ad56ff98 - Implement unsafe intrinsics for compile-time builtins (#11825)

Fri, 17 Oct 2025 00:01:54 +0000

Implement unsafe intrinsics for compile-time builtins (#11825)* Implement unsafe intrinsics for compile-time builtinsThis commit adds the extremely unsafe`wasmtime::CodeBuilder::expose_unsafe_intrinsics` method. When enabled, the Wasmbeing compiled is given access to special imports that correspond to direct,unchecked and unsandboxed, native load and store operations. These intrinsicsare intended to be used for implementing fast, inline-able versions of WASIinterfaces that are special-cased to a particular host embedding, for example.Compile-time builtins, as originally described in [theRFC](https://github.com/bytecodealliance/rfcs/pull/43), are basically made up ofthree parts:1. A function inliner2. Unsafe intrinsics3. Component composition to encapsulate the usage of unsafe intrinsics in a safeinterfacePart (1) has been implemented in Wasmtime and Cranelift for a little whilenow (see `wasmtime::Config::compiler_inlining`). This commit is part (2). Afterthis commit lands, part (3) can be done with `wac` and `wasm-compose`, althoughfollow up work is required to make the developer experience nicer and moreintegrated into Wasmtime so that the APIs can look like those proposed in theRFC.* fill out some more docs* fix non component model builds* start filling out the doc example* Factor abi params/returns out; truncate/extend pointers* Compile unsafe intrinsics on winch as well* prtest:full* have the macro define the signature* ignore tests in MIRI because MIRI can't compile Wasm* juggle pointer provenance in `Store::data[_mut]`* add a test for store data provenance and also fix it* use `VmPtr` for the store data pointer* finish writing unsafe intrinsics example* fix up docs and rules around only accessing data from `T` in a `Store`* Only reserve space for the intrinsics' `VMFuncRef`s if they are in use* use dangling pointers instead of options* Rename `StoreInner::data` to `data_no_provenance` and fix some accesses to use the method accessors* Add comments about the provenance juggling inside `StoreInner::data[_mut]`* only compile intrinsics that are usedTurns out we don't need to add phases, we already have the info available to dothis.* fix duplicate symbol names List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

89fdfa12 - Fix reverse PC to function lookups for sparse func kinds (#11766)

Tue, 30 Sep 2025 19:00:33 +0000

Fix reverse PC to function lookups for sparse func kinds (#11766)* Add failing test for index building* Fix reverse PC to function lookups for sparse func kindsWe were previously computing an offset within the kind's sparse index space, andneeded to add its sparse start index to get the actual `SparseIndex` for thefunction.Fixes #11749---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

1806c265 - Lookup functions in the text section by `FuncKey` at runtime (#11630)

Mon, 15 Sep 2025 22:35:40 +0000

Lookup functions in the text section by `FuncKey` at runtime (#11630)This commit refactors our metadata, treating compiled functions homogeneouslyand removing the need to add new tables to places like `CompiledModuleInfo`whenever we add a new kind of function. This also simplifies the process ofconstructing the metadata for a final, linked compilation artifact. Finally, itpaves the way to doing gc-sections during our linking process (which would giveus smaller code sizes by removing functions that have been inlined into everycaller, for example) as we now allow holes in certain types of function indexspaces that were previously always densely populated.We have two kinds of index spaces:1. Mostly-dense index spaces, which take O(max_index) space and provide O(1)lookups.2. Sparse index spaces, which take O(num_members) space and provideO(log n) lookups.Most of our function index spaces are currently dense, but we can tweak that inthe future if necessary.Furthermore, code size of `.cwasm` binaries has shrunk very slightly with thisrefactoring. Consider `spidermonkey.wasm`'s compiled `.cwasm`:* Size before: 218756 `.wasmtime.info` section bytes, 20052632 total bytes* Size after: 213761 `.wasmtime.info` section bytes, 20047640 total bytesThat is a 2.28% reduction on the size of the `.wasmtime.info` section, or a0.025% reduction total.However, we previously did a single metadata lookup to get the location of botha Wasm function itself and its array-to-Wasm trampoline at the same time, and inthe new version of the code two lookups are performed. This is slightly slower,as shown in our call-indirect micro-benchmark that combines lazy tableinitialization (which delays looking up the function element's location untilruntime) with indirect-calling each table element exactly once (which defeatsthe amortization of that lookup). So this micro-benchmark is both synthetic andthe worst-case scenario for this commit's change: we are measuring, as much aswe can, *only* the force-initialization-of-a-lazy-funcref-table-slot path.Ultimately, I believe that the simplification is worth the regression in thismicro-benchmark.

call-indirect micro-benchmarks results

```call-indirect/same-callee/table-init-lazy/65536-calls time: [152.77 µs 154.92 µs 157.39 µs] thrpt: [416.40 Melem/s 423.04 Melem/s 428.99 Melem/s] change: time: [−13.749% −10.205% −6.2864%] (p = 0.00 < 0.05) thrpt: [+6.7081% +11.365% +15.941%] Performance has improved.Found 13 outliers among 100 measurements (13.00%) 8 (8.00%) high mild 5 (5.00%) high severecall-indirect/different-callees/table-init-lazy/65536-calls time: [4.3564 ms 4.4641 ms 4.5843 ms] thrpt: [14.296 Melem/s 14.681 Melem/s 15.044 Melem/s] change: time: [+38.134% +44.404% +50.927%] (p = 0.00 < 0.05) thrpt: [−33.743% −30.750% −27.606%] Performance has regressed.Found 5 outliers among 100 measurements (5.00%) 2 (2.00%) high mild 3 (3.00%) high severecall-indirect/same-callee/table-init-strict/65536-calls time: [144.91 µs 148.41 µs 152.02 µs] thrpt: [431.10 Melem/s 441.58 Melem/s 452.24 Melem/s] change: time: [−13.665% −10.470% −7.2626%] (p = 0.00 < 0.05) thrpt: [+7.8313% +11.694% +15.828%] Performance has improved.Found 4 outliers among 100 measurements (4.00%) 1 (1.00%) high mild 3 (3.00%) high severecall-indirect/different-callees/table-init-strict/65536-calls time: [195.18 µs 200.67 µs 206.49 µs] thrpt: [317.38 Melem/s 326.59 Melem/s 335.77 Melem/s] change: time: [−15.936% −11.568% −7.0835%] (p = 0.00 < 0.05) thrpt: [+7.6235% +13.081% +18.957%] Performance has improved.Found 5 outliers among 100 measurements (5.00%) 5 (5.00%) high mild```

List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

cfc05638 - Make Wasmtime's `FuncKey` one-to-one with Cranelift's `ir::UserExternalName` (#11415)

Tue, 12 Aug 2025 18:38:04 +0000

Make Wasmtime's `FuncKey` one-to-one with Cranelift's `ir::UserExternalName` (#11415)* Make Wasmtime's `FuncKey` one-to-one with Cranelift's `ir::UserExternalName``FuncKey`, which used to be called `CompileKey`, is now one-to-one with`cranelift_codegen::ir::UserExternalName`, and is used for not just identifyingcompilation objects but also relocations and call-graph edges. This allows us todetermine the `StaticModuleIndex` and `DefinedFuncIndex` pair for any`cranelift_codegen::ir::FuncRef`, regardless of inlining depth, which fixes somefuzz bugs on OSS-Fuzz.This continues pushing on the idea that Wasmtime's compilation orchestration andlinking should be relatively agnostic to the kinds of things it is actuallycompiling and linking, allowing us to tweak, add, and remove new kinds of`FuncKey`s more easily. Adding a new `FuncKey` should not require modifyingrelocation resolution, for example, just a little bit of code to run theassociated compilation and optionally some code to extract metadata into ourfinal artifacts for querying at runtime. Everything in between should JustContinue Working. We still aren't all the way there yet, but this does bring usa little bit closer.Finally, in Cranelift's inlining pass, this adds a check that a block isinserted in the layout before attempting to remove it from the layout, whichwould otherwise cause panics. This was triggered by multi-level inlining andnow-unreachable blocks in the inner callees.I'll note that this does update basically all of the disas tests, or at leastnearly all of them that make function calls. This is because the namespace/indexnumbering pair changed slightly to align with `FuncKey`, but that should prettymuch be the only changes.* remove debug info from panic message, it is only available in some `cfg`s* fill out module doc comment* Fix compilation without `component-model` feature* Fix some more cfg compilations* cargo fmt* fix a wrong `&dyn Any` auto coercion; add helpful debug logging and assertions for this kind of thing List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

452086fb - Store stack maps in an ELF section (#10404)

Thu, 20 Mar 2025 19:46:14 +0000

Store stack maps in an ELF section (#10404)* Store stack maps in an ELF sectionThis commit moves the storage of stack maps from being embedded withinserde-encoded information to instead being stored in a separate ELFsection in the final executable. The motivation for this is to make thismore easily debuggable with a `wasmtime objdump` command in the futurebut this additionally should have the nice side effect of makingnon-stack-maps modules have smaller encoded information (no need toencode an empty list) and additionally make stack-maps-using-modulesfaster to decode (no serde decoding, it's already "decoded").This implements a scheme similar to the address map section wherethere's a "builder" for the section and then a separate half to decodethe section. The same basic encoding, a bit map, is used. This is likelygoing to make accessing stack maps slightly slower, but if that's anissue we can tweak the representation and align things and/or use`usize` or such.* Update crates/environ/src/compile/stack_maps.rsCo-authored-by: Andrew Brown * Review comments* More review comments* Fix MIRI test by enabling `unaligned` object feature---------Co-authored-by: Andrew Brown List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

c3aa6a53 - Change `allow(missing_docs)` to `expect(..)` (#10384)

Wed, 12 Mar 2025 18:58:45 +0000

Change `allow(missing_docs)` to `expect(..)` (#10384)This wasn't possible when `expect` was first introduced due to a changebeing required in upstream rust-lang/rust. That changerust-lang/rust#130025) has now rode enough trains to be in our MSRV, sowe can expect missing docs now instead of just allowing it. List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

70a37939 - Support executing Pulley in Wasmtime (#9744)

Fri, 06 Dec 2024 20:23:55 +0000

Support executing Pulley in Wasmtime (#9744)* Support executing Pulley in WasmtimeThis commit is the initial implementation of executing the Pulleyinterpreter from the `wasmtime` crate. This gives access to all of the`wasmtime` crate's runtime APIs backed by execution of bytecode inPulley. This builds on the previous PRs I've been making for support inPulley to culminate in testing on CI in this PR. This PR handles somefinal tidbits related to producing a runnable image that can beinterpreted by the `wasmtime` crate such as:* Pulley compilation artifacts are no longer marked as natively executable, just read-only.* Pulley compilation artifacts include wasm-to-array trampolines like normal platforms (removes a pulley special-case).* Dispatch of host calls from Pulley to the Wasmtime runtime are implemented.* Pulley's list of panicking wasm features is slimmed down as most are covered by "this lowering isn't supported" errors.* Execution of wasm code now has an `if` to see whether Pulley is enabled within a `Store` or not.* Traps and basic "unwinding" of the pulley stack are implemented (e.g. a "pulley version" of `setjmp` and `longjmp`, sort of)* Halting the interpreter has been refactored to help shrink the size of `ControlFlow` and handle metadata with each done state.Some minor refactorings are also included here and there along with afew fixes here and there necessary to get tests passing.The next major part of this commit is updates to our `wast` test suiteand executing all `*.wast` files. Pulley is now executed by default forall files as a new execution engine. This means that all platforms in CIwill start executing Pulley tests. At this time almost all tests areflagged as "expected to fail" but there are a small handful ofallow-listed tests which are expected to pass. This exact list willchange over time as CLIF lowerings are implemented and the interpreteris extended.Follow-up PRs will extend the testing strategy further such as:* Extending `#[wasmtime_test]` to include Pulley in addition to Winch.* Getting testing set up on CI for 32-bit platforms.prtest:full* Fix pulley fuzz build* Fix clippy lints* Shuffle around some `#[cfg]`'d code* Remove unused imports* Update feature sets testing MIRIEnable pulley for wasmtime/wasmtime-cli and also enable all features forwasmtime-environ* Round up pulley's page size to 64k* Skip pulley tests on s390x for now* Add a safety rail for matching a pulley target to the host* Fix more pulley tests on s390x* Review comments* Fix fuzz build List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

45b60bd6 - Start using `#[expect]` instead of `#[allow]` (#9696)

Mon, 02 Dec 2024 17:19:20 +0000

Start using `#[expect]` instead of `#[allow]` (#9696)* Start using `#[expect]` instead of `#[allow]`In Rust 1.81, our new MSRV, a new feature was added to Rust to use`#[expect]` to control lint levels. This new lint annotation willsilence a lint but will itself cause a lint if it doesn't actuallysilence anything. This is quite useful to ensure that annotations don'tget stale over time.Another feature is the ability to use a `reason` directive on theattribute with a string explaining why the attribute is there. Thisstring is then rendered in compiler messages if a warning or errorhappens.This commit migrates applies a few changes across the workspace:* Some `#[allow]` are changed to `#[expect]` with a `reason`.* Some `#[allow]` have a `reason` added if the lint conditionally fires (mostly related to macros).* Some `#[allow]` are removed since the lint doesn't actually fire.* The workspace configures `clippy::allow_attributes_without_reason = 'warn'` as a "ratchet" to prevent future regressions.* Many crates are annotated to allow `allow_attributes_without_reason` during this transitionary period.The end-state is that all crates should use`#[expect(..., reason = "...")]` for any lint that unconditionally firesbut is expected. The `#[allow(..., reason = "...")]` lint should be usedfor conditionally firing lints, primarily in macro-related code.The `allow_attributes_without_reason = 'warn'` level is intended to bepermanent but the transitionary`#[expect(clippy::allow_attributes_without_reason)]` crate annotationsto go away over time.* Fix adapter buildprtest:full* Fix one-core build of icache coherence* Use `allow` for missing_docsWork around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn'tfixed for our MSRV at this time.* More MSRV compat List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

ae3bf36f - Move JIT debug image registration to CodeMemory (#9470)

Wed, 16 Oct 2024 23:04:03 +0000

Move JIT debug image registration to CodeMemory (#9470)* Move JIT debug image registration to CodeMemoryJIT images correspond to ELF images, which may representmultiple modules within a single component.* Add the last ifdef* Remove ManuallyDrop as per feedback List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.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_artifacts.rs

52f6c8b6 - Wasmtime: Allow compiling Wasm modules with Pulley (#9240)

Fri, 13 Sep 2024 16:16:18 +0000

Wasmtime: Allow compiling Wasm modules with Pulley (#9240)* Wasmtime: Allow compiling Wasm modules with PulleyThis does not yet add support for running Wasm modules compiled withPulley, but it does allow compiling them. This is a first step towardsintegrating Pulley into Wasmtime itself.This is also enough to get basic `tests/disas` tests working with Pulley.* fix clippy* Use named struct instead of tuple List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

5393c2bf - Reduce typo count (#8951)

Mon, 15 Jul 2024 14:26:59 +0000

Reduce typo count (#8951) List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs

1d11b265 - Remove the native ABI calling convention from Wasmtime (#8629)

Fri, 17 May 2024 04:28:11 +0000

Remove the native ABI calling convention from Wasmtime (#8629)* Remove the native ABI calling convention from WasmtimeThis commit proposes removing the "native abi" calling convention usedin Wasmtime. For background this ABI dates back to the origins ofWasmtime. Originally Wasmtime only had `Func::call` and eventually Iadded `TypedFunc` with `TypedFunc::call` and `Func::wrap` for a fasterpath. At the time given the state of trampolines it was easiest to callWebAssembly code directly without any trampolines using the native ABIthat wasm used at the time. This is the original source of the nativeABI and it's persisted over time under the assumption that it's fasterthan the array ABI due to keeping arguments in registers rather thanspilling them to the stack.Over time, however, this design decision of using the native ABI has notaged well. Trampolines have changed quite a lot in the meantime and it'sno longer possible for the host to call wasm without a trampoline, forexample. Compilations nowadays maintain both native and arraytrampolines for wasm functions in addition to host functions. There's alarge split between `Func::new` and `Func::wrap`. Overall, there's quitea lot of weight that we're pulling for the design decision of using thenative ABI.Functionally this hasn't ever really been the end of the world.Trampolines aren't a known issue in terms of performance or code size.There's no known faster way to invoke WebAssembly from the host (orvice-versa). One major downside of this design, however, is that`Func::new` requires Cranelift as a backend to exist. This is due to thefact that it needs to synthesize various entries in the matrix of ABIswe have that aren't available at any other time. While this is itselfnot the worst of issues it means that the C API cannot be built withouta compiler because the C API does not have access to `Func::wrap`.Overall I'd like to reevaluate given where Wasmtime is today whether itmakes sense to keep the native ABI trampolines. Sure they're supposed tobe fast, but are they really that much faster than the array-call ABI asan alternative? This commit is intended to measure this.This commit removes the native ABI calling convention entirely. Forexample `VMFuncRef` is now one pointer smaller. All of `TypedFunc` nowuses `*mut ValRaw` for loads/stores rather than dealing with ABIbusiness. The benchmarks with this PR are:* `sync/no-hook/core - host-to-wasm - typed - nop` - 5% faster* `sync/no-hook/core - host-to-wasm - typed - nop-params-and-results` - 10% slower* `sync/no-hook/core - wasm-to-host - typed - nop` - no change* `sync/no-hook/core - wasm-to-host - typed - nop-params-and-results` - 7% fasterThese numbers are a bit surprising as I would have suspected no changein both "nop" benchmarks as well as both being slower in theparams-and-results benchmarks. Regardless it is apparent that this isnot a major change in terms of performance given Wasmtime's currentstate. In general my hunch is that there are more expensive sources ofoverhead than reads/writes from the stack when dealing with wasm values(e.g. trap handling, store management, etc).Overall this commit feels like a large simplification of what wecurrently do in `TypedFunc`:* The number of ABIs that Wasmtime deals with is reduced by one. ABIs are pretty much always tricky and having fewer moving parts should help improve the understandability of the system.* All of the `WasmTy` trait methods and `TypedFunc` infrastructure is simplified. Traits now work with simple `load`/`store` methods rather than various other flavors of conversion.* The multi-return-value handling of the native ABI is all gone now which gave rise to significant complexity within Wasmtime's Cranelift translation layer in addition to the `TypedFunc` backing traits.* This aligns components and core wasm where components always use the array ABI and now core wasm additionally will always use the array ABI when communicating with the host.I'll note that this still leaves a major ABI "complexity" with respectto native functions do not have a wasm ABI function pointer untilthey're "attached" to a `Store` with a `Module`. That's required toavoid needing Cranelift for creating host functions and that property isstill true today. This is a bit simpler to understand though now that`Func::new` and `Func::wrap` are treated uniformly rather than one beingspecial-cased.* Fix miri unsafetyprtest:full List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.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_artifacts.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_artifacts.rs

1a7de7cc - Add a `compile` feature to `wasmtime-environ` (#8250)

Thu, 28 Mar 2024 16:07:12 +0000

Add a `compile` feature to `wasmtime-environ` (#8250)* Add a `compile` feature to `wasmtime-environ`This commit adds a compile-time feature to remove some dependencies ofthe `wasmtime-environ` crate. This compiles out support for compilingmodules/components and makes the crate slimmer in terms of amount ofcode compiled along with its dependencies. Much of this should alreadyhave been statically removed by native linkers so this likely won't haveany compile-size impact, but it's a nice-to-have in terms oforganization.This has a fair bit of shuffling around of code, but apart fromrenamings and movement there are no major changes here.* Fix compile issue* Gate `ModuleTranslation` and its methods on `compile`* Fix doc link* Fix doc link List of files: /wasmtime-44.0.1/crates/environ/src/module_artifacts.rs