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

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

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 c

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

show more ...

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 (patchable
calls in #12061 a

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 (patchable
calls in #12061 and #12101, private copies of code in #12051, and all
the prior debug event and instrumentation infrastructure) to implement
breakpoints in the guest debugger.

These are implemented in the way we have planned in #11964: each
sequence point (location prior to a Wasm opcode) is now a patchable call
instruction, patched out (replaced with NOPs) by default. When patched
in, the breakpoint callsite calls a trampoline with the `patchable` ABI
which then invokes the `breakpoint` hostcall. That hostcall emits the
debug 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 to
do *all* patches in all modules registered in the `Store` when that flag
is 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 on
macOS/aarch64 that is consistent with patched-in breakpoint calls still
being incorrectly cached after we remove them and republish the code.

There is a longstanding issue in #3310 tracking proper icache coherence
handling on aarch64. We implemented this for Linux with the `membarrier`
syscall but never did so for macOS. Maybe this is the first point at
which it matters, because code was always loaded at new addresses (hence
did not have coherence issues because nothing would have been cached)
previously.

prtest:full

* Review feedback: use `next_multiple_of`.

show more ...

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

* Implement unsafe intrinsics for compile-time builtins

This commit adds the extremely unsafe
`wasmtime::CodeBuilder::expose_unsafe_in

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

* Implement unsafe intrinsics for compile-time builtins

This commit adds the extremely unsafe
`wasmtime::CodeBuilder::expose_unsafe_intrinsics` method. When enabled, the Wasm
being compiled is given access to special imports that correspond to direct,
unchecked and unsandboxed, native load and store operations. These intrinsics
are intended to be used for implementing fast, inline-able versions of WASI
interfaces that are special-cased to a particular host embedding, for example.

Compile-time builtins, as originally described in [the
RFC](https://github.com/bytecodealliance/rfcs/pull/43), are basically made up of
three parts:

1. A function inliner
2. Unsafe intrinsics
3. Component composition to encapsulate the usage of unsafe intrinsics in a safe
interface

Part (1) has been implemented in Wasmtime and Cranelift for a little while
now (see `wasmtime::Config::compiler_inlining`). This commit is part (2). After
this commit lands, part (3) can be done with `wac` and `wasm-compose`, although
follow up work is required to make the developer experience nicer and more
integrated into Wasmtime so that the APIs can look like those proposed in the
RFC.

* 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<T>`

* 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 used

Turns out we don't need to add phases, we already have the info available to do
this.

* fix duplicate symbol names

show more ...

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 kinds

We were previously computing an o

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 kinds

We were previously computing an offset within the kind's sparse index space, and
needed to add its sparse start index to get the actual `SparseIndex` for the
function.

Fixes #11749

---------

Co-authored-by: Alex Crichton <[email protected]>

show more ...

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

This commit refactors our metadata, treating compiled functions homogeneously
and removing the need to add new tables to places

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

This commit refactors our metadata, treating compiled functions homogeneously
and removing the need to add new tables to places like `CompiledModuleInfo`
whenever we add a new kind of function. This also simplifies the process of
constructing the metadata for a final, linked compilation artifact. Finally, it
paves the way to doing gc-sections during our linking process (which would give
us smaller code sizes by removing functions that have been inlined into every
caller, for example) as we now allow holes in certain types of function index
spaces 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 provide
O(log n) lookups.

Most of our function index spaces are currently dense, but we can tweak that in
the future if necessary.

Furthermore, code size of `.cwasm` binaries has shrunk very slightly with this
refactoring. 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 bytes

That is a 2.28% reduction on the size of the `.wasmtime.info` section, or a
0.025% reduction total.

However, we previously did a single metadata lookup to get the location of both
a Wasm function itself and its array-to-Wasm trampoline at the same time, and in
the new version of the code two lookups are performed. This is slightly slower,
as shown in our call-indirect micro-benchmark that combines lazy table
initialization (which delays looking up the function element's location until
runtime) with indirect-calling each table element exactly once (which defeats
the amortization of that lookup). So this micro-benchmark is both synthetic and
the worst-case scenario for this commit's change: we are measuring, as much as
we can, *only* the force-initialization-of-a-lazy-funcref-table-slot path.

Ultimately, I believe that the simplification is worth the regression in this
micro-benchmark.

<details>

<summary>call-indirect micro-benchmarks results</summary>

```
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 severe
call-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 severe
call-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 severe
call-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
```

</details>

show more ...

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 call

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 identifying
compilation objects but also relocations and call-graph edges. This allows us to
determine the `StaticModuleIndex` and `DefinedFuncIndex` pair for any
`cranelift_codegen::ir::FuncRef`, regardless of inlining depth, which fixes some
fuzz bugs on OSS-Fuzz.

This continues pushing on the idea that Wasmtime's compilation orchestration and
linking should be relatively agnostic to the kinds of things it is actually
compiling and linking, allowing us to tweak, add, and remove new kinds of
`FuncKey`s more easily. Adding a new `FuncKey` should not require modifying
relocation resolution, for example, just a little bit of code to run the
associated compilation and optionally some code to extract metadata into our
final artifacts for querying at runtime. Everything in between should Just
Continue Working. We still aren't all the way there yet, but this does bring us
a little bit closer.

Finally, in Cranelift's inlining pass, this adds a check that a block is
inserted in the layout before attempting to remove it from the layout, which
would otherwise cause panics. This was triggered by multi-level inlining and
now-unreachable blocks in the inner callees.

I'll note that this does update basically all of the disas tests, or at least
nearly all of them that make function calls. This is because the namespace/index
numbering pair changed slightly to align with `FuncKey`, but that should pretty
much 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

show more ...

Store stack maps in an ELF section (#10404)

* Store stack maps in an ELF section

This commit moves the storage of stack maps from being embedded within
serde-encoded information to instead being st

Store stack maps in an ELF section (#10404)

* Store stack maps in an ELF section

This commit moves the storage of stack maps from being embedded within
serde-encoded information to instead being stored in a separate ELF
section in the final executable. The motivation for this is to make this
more easily debuggable with a `wasmtime objdump` command in the future
but this additionally should have the nice side effect of making
non-stack-maps modules have smaller encoded information (no need to
encode an empty list) and additionally make stack-maps-using-modules
faster to decode (no serde decoding, it's already "decoded").

This implements a scheme similar to the address map section where
there's a "builder" for the section and then a separate half to decode
the section. The same basic encoding, a bit map, is used. This is likely
going to make accessing stack maps slightly slower, but if that's an
issue we can tweak the representation and align things and/or use
`usize` or such.

* Update crates/environ/src/compile/stack_maps.rs

Co-authored-by: Andrew Brown <[email protected]>

* Review comments

* More review comments

* Fix MIRI test by enabling `unaligned` object feature

---------

Co-authored-by: Andrew Brown <[email protected]>

show more ...

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

This wasn't possible when `expect` was first introduced due to a change
being required in upstream rust-lang/rust. That change
rust-lang/rust#13

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

This wasn't possible when `expect` was first introduced due to a change
being required in upstream rust-lang/rust. That change
rust-lang/rust#130025) has now rode enough trains to be in our MSRV, so
we can expect missing docs now instead of just allowing it.

show more ...

Support executing Pulley in Wasmtime (#9744)

* Support executing Pulley in Wasmtime

This commit is the initial implementation of executing the Pulley
interpreter from the `wasmtime` crate. This gi

Support executing Pulley in Wasmtime (#9744)

* Support executing Pulley in Wasmtime

This commit is the initial implementation of executing the Pulley
interpreter from the `wasmtime` crate. This gives access to all of the
`wasmtime` crate's runtime APIs backed by execution of bytecode in
Pulley. This builds on the previous PRs I've been making for support in
Pulley to culminate in testing on CI in this PR. This PR handles some
final tidbits related to producing a runnable image that can be
interpreted 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<Done>` and handle metadata with each done state.

Some minor refactorings are also included here and there along with a
few fixes here and there necessary to get tests passing.

The next major part of this commit is updates to our `wast` test suite
and executing all `*.wast` files. Pulley is now executed by default for
all files as a new execution engine. This means that all platforms in CI
will start executing Pulley tests. At this time almost all tests are
flagged as "expected to fail" but there are a small handful of
allow-listed tests which are expected to pass. This exact list will
change over time as CLIF lowerings are implemented and the interpreter
is 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 MIRI

Enable pulley for wasmtime/wasmtime-cli and also enable all features for
wasmtime-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

show more ...

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

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 will
silence a lint but will itself cause a lint if it doesn't actually
silence anything. This is quite useful to ensure that annotations don't
get stale over time.

Another feature is the ability to use a `reason` directive on the
attribute with a string explaining why the attribute is there. This
string is then rendered in compiler messages if a warning or error
happens.

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 fires
but is expected. The `#[allow(..., reason = "...")]` lint should be used
for conditionally firing lints, primarily in macro-related code.
The `allow_attributes_without_reason = 'warn'` level is intended to be
permanent but the transitionary
`#[expect(clippy::allow_attributes_without_reason)]` crate annotations
to go away over time.

* Fix adapter build

prtest:full

* Fix one-core build of icache coherence

* Use `allow` for missing_docs

Work around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn't
fixed for our MSRV at this time.

* More MSRV compat

show more ...

Move JIT debug image registration to CodeMemory (#9470)

* Move JIT debug image registration to CodeMemory

JIT images correspond to ELF images, which may represent
multiple modules within a single c

Move JIT debug image registration to CodeMemory (#9470)

* Move JIT debug image registration to CodeMemory

JIT images correspond to ELF images, which may represent
multiple modules within a single component.

* Add the last ifdef

* Remove ManuallyDrop as per feedback

show more ...

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 bee

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 to
maintain this split. This commit merges the `wasmtime-types` crate back
into `wasmtime-environ`.

show more ...

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

* Wasmtime: Allow compiling Wasm modules with Pulley

This does not yet add support for running Wasm modules compiled with
Pulley, but it d

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

* Wasmtime: Allow compiling Wasm modules with Pulley

This does not yet add support for running Wasm modules compiled with
Pulley, but it does allow compiling them. This is a first step towards
integrating 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

show more ...

Reduce typo count (#8951)

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

* Remove the native ABI calling convention from Wasmtime

This commit proposes removing the "native abi" calling convention used
in Was

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

* Remove the native ABI calling convention from Wasmtime

This commit proposes removing the "native abi" calling convention used
in Wasmtime. For background this ABI dates back to the origins of
Wasmtime. Originally Wasmtime only had `Func::call` and eventually I
added `TypedFunc` with `TypedFunc::call` and `Func::wrap` for a faster
path. At the time given the state of trampolines it was easiest to call
WebAssembly code directly without any trampolines using the native ABI
that wasm used at the time. This is the original source of the native
ABI and it's persisted over time under the assumption that it's faster
than the array ABI due to keeping arguments in registers rather than
spilling them to the stack.

Over time, however, this design decision of using the native ABI has not
aged well. Trampolines have changed quite a lot in the meantime and it's
no longer possible for the host to call wasm without a trampoline, for
example. Compilations nowadays maintain both native and array
trampolines for wasm functions in addition to host functions. There's a
large split between `Func::new` and `Func::wrap`. Overall, there's quite
a lot of weight that we're pulling for the design decision of using the
native 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 (or
vice-versa). One major downside of this design, however, is that
`Func::new` requires Cranelift as a backend to exist. This is due to the
fact that it needs to synthesize various entries in the matrix of ABIs
we have that aren't available at any other time. While this is itself
not the worst of issues it means that the C API cannot be built without
a compiler because the C API does not have access to `Func::wrap`.

Overall I'd like to reevaluate given where Wasmtime is today whether it
makes sense to keep the native ABI trampolines. Sure they're supposed to
be fast, but are they really that much faster than the array-call ABI as
an alternative? This commit is intended to measure this.

This commit removes the native ABI calling convention entirely. For
example `VMFuncRef` is now one pointer smaller. All of `TypedFunc` now
uses `*mut ValRaw` for loads/stores rather than dealing with ABI
business. 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% faster

These numbers are a bit surprising as I would have suspected no change
in both "nop" benchmarks as well as both being slower in the
params-and-results benchmarks. Regardless it is apparent that this is
not a major change in terms of performance given Wasmtime's current
state. In general my hunch is that there are more expensive sources of
overhead 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 we
currently 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 respect
to native functions do not have a wasm ABI function pointer until
they're "attached" to a `Store` with a `Module`. That's required to
avoid needing Cranelift for creating host functions and that property is
still true today. This is a bit simpler to understand though now that
`Func::new` and `Func::wrap` are treated uniformly rather than one being
special-cased.

* Fix miri unsafety

prtest:full

show more ...

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

* wasmtime(gc): Fix wasm-to-native trampoline lookup for subtyping

Previously, we would look up a wasm-to-native trampoline

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

* wasmtime(gc): Fix wasm-to-native trampoline lookup for subtyping

Previously, we would look up a wasm-to-native trampoline in the Wasm module
based on the host function's type. With Wasm GC and subtyping, this becomes
problematic because a Wasm module can import a function of type `T` but the host
can define a function of type `U` where `U <: T`. And if the Wasm has never
defined type `U` then it wouldn't have a trampoline for it. But our trampolines
don't actually care, they treat all reference values within the same type
hierarchy identically. So the trampoline for `T` would have worked in
practice. But once we find a trampoline for a function, we cache it and reuse it
every time that function is used in the same store again. Even if the function
is imported with its precise type somewhere else. So then we would have a
trampoline of the wrong type. But this happened to be okay in practice because
the trampolines happen not to inspect their arguments or do anything with them
other than forward them between calling convention locations. But relying on
that accidental invariant seems fragile and like a gun aimed at the future's
feet.

This commit makes that invariant non-accidental, centering it and hopefully
making it less fragile by doing so, by making every function type have an
associated "trampoline type". A trampoline type is the original function type
but where all the reference types in its params and results are replaced with
the nullable top versions, e.g. `(ref $my_struct)` is replaced with `(ref null
any)`. Often a function type is its own associated trampoline type, as is the
case for all functions that don't have take or return any references, for
example. Then, all trampoline lookup begins by first getting the trampoline type
of the actual function type, or actual import type, and then only afterwards
finding for the pre-compiled trampoline in the Wasm module.

Fixes https://github.com/bytecodealliance/wasmtime/issues/8432

Co-Authored-By: Jamey Sharp <[email protected]>

* Fix no-std build

---------

Co-authored-by: Jamey Sharp <[email protected]>

show more ...

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 being
tagged with `#![no_

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 being
tagged with `#![no_std]`. Only the `component-model` and `gc` features
are able to be built without `std`, all other features will implicitly
activate the `std` feature as they currently require it one way or
another. CI is updated to build `wasmtime-environ` with these two
features active on a no_std platform.

This additionally, for the workspace, disables the `std` feature for the
`target-lexicon`, `indexmap`, `object`, and `gimli` dependencies. For
object/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` and
additionally `hashbrown` was added for explicit usage of maps.

* Always enable `std` for environ for now

prtest:full

* Add some more std features

show more ...

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 of
the `wasmtime-environ` c

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 of
the `wasmtime-environ` crate. This compiles out support for compiling
modules/components and makes the crate slimmer in terms of amount of
code compiled along with its dependencies. Much of this should already
have been statically removed by native linkers so this likely won't have
any compile-size impact, but it's a nice-to-have in terms of
organization.

This has a fair bit of shuffling around of code, but apart from
renamings and movement there are no major changes here.

* Fix compile issue

* Gate `ModuleTranslation` and its methods on `compile`

* Fix doc link

* Fix doc link

show more ...

Update some CI dependencies (#7983)

* Update some CI dependencies

* Update to the latest nightly toolchain
* Update mdbook
* Update QEMU for cross-compiled testing
* Update `cargo nextest` for usag

Update some CI dependencies (#7983)

* Update some CI dependencies

* Update to the latest nightly toolchain
* Update mdbook
* Update QEMU for cross-compiled testing
* Update `cargo nextest` for usage with MIRI

prtest:full

* Remove lots of unnecessary imports

* Downgrade qemu as 8.2.1 seems to segfault

* Remove more imports

* Remove unused winch trait method

* Fix warnings about unused trait methods

* More unused imports

* More unused imports

show more ...

Shuffle some items around in `wasmtime` (#7839)

* Shuffle some items around in `wasmtime`

This is a follow-up to #7766 with some more changes and reorganization.
These are some small items here and

Shuffle some items around in `wasmtime` (#7839)

* Shuffle some items around in `wasmtime`

This is a follow-up to #7766 with some more changes and reorganization.
These are some small items here and there which shouldn't have any
actual impact on functionality but are intended to reorganize a bit.
Changes here include:

* Move component artifact definitions to `wasmtime-environ` as core
module ones already live there.
* Rename the module with module artifacts from `instantiate` to
`module_artifacts`.
* Make `wasmtime-jit-icache-coherence` an optional dependency as only
the `runtime` feature requires it.
* Reorganize serialized metadata for wasmtime ELF files to consolidate
everything back into `wasmtime::engine::serialization`. This is to
prevent the definition of the serialization format being spread across
a few files.
* Touching up the `serialization` module to compile in all builds of the
`wasmtime` crate.

* fix docs typo

---------

Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...