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

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

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

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...

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

* Fix assertion in `PartialEq` for `RegisteredType` again

It is possible for two `

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

* Fix assertion in `PartialEq` for `RegisteredType` again

It 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 they
are in different rec groups or even if they are at different indices within the
same 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}`s

Rather than canonicalizing them on demand in functions like
`{Func,Global,Table}Type::from_wasmtime` and other places. Instead, we do it in
one place, up front, so that it is very unlikely we miss anything. Doing this
involves changing some things from `ModuleInternedTypeIndex`es to
`EngineOrModuleTypeIndex`es in `wasmtime_environ`, which means that a bunch of
uses of those things need to unwrap the appropriate kind of type index at usage
sites (e.g. compilation uses will unwrap `ModuleInternedTypeIndex`es, runtime
uses usage will unwrap `VMSharedTypeIndex`es). And it additionally required
implementing the `TypeTrace` trait for a handful of things to unlock the
provided `canonicalize_for_runtime_usage` trait method for those things.

All this machinery is required to avoid an assertion failure in the regression
test introduced in the previous commit, which was triggered because we were
failing to canonicalize type indices inside `ExternType`s for runtime usage on
some code paths. We shouldn't have to play that kind of whack-a-mole in the
future, thanks to this new approach.

* Fix a warning in no-default-features builds

* Fix another warning in weird cfg builds

show more ...

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

* Enable `impl-trait-overcaptures` 2024 transition lint

This lint detects cases where returning `impl Trait` will work
differently in 2

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

* Enable `impl-trait-overcaptures` 2024 transition lint

This lint detects cases where returning `impl Trait` will work
differently in 2024 than in the current 2021 edition. Ambiguities are
resolved with `use<..>` syntax stabilized in Rust 1.82.0 to mean the
same 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

show more ...

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

* Enable some miscellaneous GC spec tests

These weren't caught by our checks that `should_fail`

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

* Enable some miscellaneous GC spec tests

These weren't caught by our checks that `should_fail` tests do not pass, I think
because they only contain modules that should validate, and not any actual
assertions.

* Require declared subtyping when linking module import/export functions

We were previously incorrectly doing a (shallow) match on structure when we
should have been doing a subtyping check.

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 ...

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

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 <[email protected]>

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 ...

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

This commit adds support for defining array types from Wasm or the host, and
managing them inside the engine's types registry. It does not introduce

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

This commit adds support for defining array types from Wasm or the host, and
managing them inside the engine's types registry. It does not introduce support
for allocating or manipulating array values. That functionality will come in
future pull requests.

show more ...

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 o

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 types
in the `wasmtime-environ` crate on the `compile` feature. This helps
bring in less code when the feature is disabled and helps exclude some
dependencies for the upcoming `no_std` migration as well.

This commit doesn't change anything, it's just moving code around.

* Remove no-longer-needed import

prtest:full

show more ...

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

* Rename `WasmHeapType::Concrete(_)` to `WasmHeapType::ConcreteFunc(_)`

* Rename `wasmtime::HeapType::Co

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-types

Right 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 make
sure that `match`es are exhaustive for when we add new enum variants. (Although
I did add an `unwrap_func` helper for use when it is clear that the type should
be a function type, and if it isn't then we should panic.)

show more ...

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

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

* Wasmtime: Finish support for the typed function references proposal

While we supported the function references proposal

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

* Wasmtime: Finish support for the typed function references proposal

While we supported the function references proposal inside Wasm, we didn't
support it on the "outside" in the Wasmtime embedder APIs. So much of the work
here is exposing typed function references, and their type system updates, in
the 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 manage
lifetimes of types that reference other types. This wasn't previously an issue
because the only thing that could reference types that reference other types was
a Wasm module that added all the types that could reference each other at the
same time and removed them all at the same time. But now that the previously
discussed work to expose these things in the embedder API is done, type lifetime
management in the registry becomes a little trickier because the embedder might
grab a reference to a type that references another type, and then unload the
Wasm module that originally defined that type, but then the user should still be
able use that type and the other types it transtively references. Before, we
were refcounting individual registry entries. Now, we still are refcounting
individual entries, but now we are also accounting for type-to-type references
and adding a new type to the registry will increment the refcounts of each of
the types that it references, and removing a type from the registry will
decrement 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 the
WebAssembly function's actual declared return type in `Func::typed`. And for
param types, you can always use a subtype of the Wasm function's actual declared
param type. Doing these things essentially erases information but is always
correct. But additionally, for functions which take a reference to a concrete
type as a parameter, you can also use the concrete type's supertype. Consider a
WebAssembly function that takes a reference to a function with a concrete type:
`(ref null <func type index>)`. In this scenario, there is no static
`wasmtime::Foo` Rust type that corresponds to that particular Wasm-defined
concrete reference type because Wasm modules are loaded dynamically at
runtime. You *could* do `f.typed::<Option<NoFunc>, ()>()`, and while that is
correctly typed and valid, it is often overly restrictive. The only value you
could call the resulting typed function with is the null function reference, but
we'd like to call it with non-null function references that happen to be of the
correct type. Therefore, `f.typed<Option<Func>, ()>()` is also allowed in this
case, even though `Option<Func>` represents `(ref null func)` which is the
supertype, not subtype, of `(ref null <func type index>)`. This does imply some
minimal dynamic type checks in this case, but it is supported for better
ergonomics, to enable passing non-null references into the function.

We can investigate whether it is possible to use generic type parameters and
combinators to define Rust types that precisely match concrete reference types
in future, follow-up pull requests. But for now, we've made things usable, at
least.

Finally, this also takes the first baby step towards adding support for the Wasm
GC proposal. Right now the only thing that is supported is `nofunc` references,
and this was mainly to make testing function reference subtyping easier. But
that does mean that supporting `nofunc` references entailed also adding a
`wasmtime::NoFunc` type as well as the `Config::wasm_gc(enabled)` knob. So we
officially have an in-progress implementation of Wasm GC in Wasmtime after this
PR 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 methods

Ever 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 for
embedders.

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

prtest:full

* Fix size assertion on s390x

show more ...

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

Purely mechanical, not functional changes.

This better matches the wording of the spec and of `wasmparser`, especially as
we pre

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

Purely mechanical, not functional changes.

This better matches the wording of the spec and of `wasmparser`, especially as
we prepare to implement Wasm GC, where there can be references to concrete types
that are not functions (and are structs or arrays instead).

show more ...

wasmtime: Rename `SignatureFooBar` to `TypeFooBar` (#7826)

* wasmtime: Rename `SignatureFooBar` to `TypeFooBar`

No functional changes, just the following mechanical renames:

* `VMSharedSignatureIn

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 more

This is intended to start paving the way for Wasm GC support, where there are
more than just function signatures in a Wasm module's type section, and we are
going to need to register non-function-signature types in the registry as well,
for things like casting between reference types and passing reference types
across Wasm modules.

* Reintroduce different index types for module-interned types vs Wasm-index-space types

* Fix a couple unused-import warnings

show more ...

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

This commit updates to the latest wasm-tools and `wit-bindgen` to bring
the family of crates forward. This update notably includes Nick's work
on packe

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

This commit updates to the latest wasm-tools and `wit-bindgen` to bring
the family of crates forward. This update notably includes Nick's work
on packed indices in the `wasmparser` crate for validation for the
upcoming 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's
own type information but additionally `wasmparser`'s type information
throughout translation.

This required a fair bit of refactoring to get this working but no
change in functionality is intended, only a different way of doing
everything prior.

show more ...

Decouple `serde` from its `derive` crate (#6917)

By not activating the `derive` feature on `serde`, the compilation speed
can be improved by a lot. This is because `serde` can then compile in
parall

Decouple `serde` from its `derive` crate (#6917)

By not activating the `derive` feature on `serde`, the compilation speed
can be improved by a lot. This is because `serde` can then compile in
parallel to `serde_derive`, allowing it to finish compilation possibly
even 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 a
project is, is primarly determined by the depth of dependencies rather
than the width. In other words, a crate's compile times aren't affected
by how many crates it depends on, but rather by the longest chain of
dependencies that it needs to wait on. In many cases `serde` is part of
that long chain, as it is part of a long chain if the `derive` feature
is 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 compile
times get much better.

Check this issue for a deeper elaboration:
https://github.com/serde-rs/serde/issues/2584

For `wasmtime` I'm seeing a reduction from 24.75s to 22.45s when
compiling 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 so
some of wasmtime's dependencies can start compiling.

To measure the full effect, the dependencies can't by themselves
activate the `derive` feature. I've upstreamed a patch for
`fxprof-processed-profile` which was the only dependency that activated
it for `wasmtime` (not yet published to crates.io). `wasmtime-cli` and
co. may need patches for their dependencies to see a similar
improvement.

show more ...

Initial skeleton of some component model processing (#4005)

* Initial skeleton of some component model processing

This commit is the first of what will likely be many to implement the
component

Initial skeleton of some component model processing (#4005)

* Initial skeleton of some component model processing

This commit is the first of what will likely be many to implement the
component model proposal in Wasmtime. This will be structured as a
series of incremental commits, most of which haven't been written yet.
My hope is to make this incremental and over time to make this easier to
review and easier to test each step in isolation.

Here much of the skeleton of how components are going to work in
Wasmtime is sketched out. This is not a complete implementation of the
component model so it's not all that useful yet, but some things you can
do are:

* Process the type section into a representation amenable for working
with in Wasmtime.
* Process the module section and register core wasm modules.
* Process the instance section for core wasm modules.
* Process core wasm module imports.
* Process core wasm instance aliasing.
* Ability to compile a component with core wasm embedded.
* Ability to instantiate a component with no imports.
* Ability to get functions from this component.

This is already starting to diverge from the previous module linking
representation where a `Component` will try to avoid unnecessary
metadata about the component and instead internally only have the bare
minimum necessary to instantiate the module. My hope is we can avoid
constructing most of the index spaces during instantiation only for it
to all ge thrown away. Additionally I'm predicting that we'll need to
see through processing where possible to know how to generate adapters
and where they are fused.

At this time you can't actually call a component's functions, and that's
the next PR that I would like to make.

* Add tests for the component model support

This commit uses the recently updated wasm-tools crates to add tests for
the component model added in the previous commit. This involved updating
the `wasmtime-wast` crate for component-model changes. Currently the
component support there is quite primitive, but enough to at least
instantiate components and verify the internals of Wasmtime are all
working correctly. Additionally some simple tests for the embedding API
have also been added.

show more ...