Debugging: add integration test with LLDB and some minor tweaks. (#12856)

This PR adds:

- An integration-test that runs LLDB against the Wasmtime CLI to
verify basic debugging functionality, simi

Debugging: add integration test with LLDB and some minor tweaks. (#12856)

This PR adds:

- An integration-test that runs LLDB against the Wasmtime CLI to
verify basic debugging functionality, similar to the existing
native-debug tests.

- A CI job that runs the above in CI.

- Some minor tweaks to the gdbstub debugger design:
- Rather than the initial single-step to get to the first Wasm
instruction where module(s) will be instantiated into the store
and visible to the debugger, we pre-register modules with the
store eagerly. This avoids the slightly hacky flow and also is a
preparation step for `wasmtime serve` debugging, where we can't
single-step into execution eagerly (because execution doesn't
start at all until an HTTP request arrives).
- Add a separate message-printing path for "debugger info messages",
allowing us to print the "debugger is listening on <PORT>" message
without inheriting stderr for the whole debugger component
environment. This message is necessary for the above integration
test (it parses the message to determine when the debuggee is ready).

show more ...

Use `TryBTreeMap` in the store's `ModuleRegistry` (#12846)

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

Refactor the `TypeRegistry` to partially handle OOM (#12500)

* Refactor the `TypeRegistry` to partially handle OOM

This refactors the type registry to be more "columnar" when registering the
types

Refactor the `TypeRegistry` to partially handle OOM (#12500)

* Refactor the `TypeRegistry` to partially handle OOM

This refactors the type registry to be more "columnar" when registering the
types within a rec group, so that we

* Add all the types themselves
* Add the rec group metadata for all types in the rec group
* Add the supertypes metadata for all types in the rec group
* Etc...

Instead of adding one type, its rec group metadata, its supertypes metadata,
etc... and then moving on to the next type.

This makes it easier to pre-reserve space and roll back changes on OOM errors.

This is part of https://github.com/bytecodealliance/wasmtime/issues/12069 and
the OOM handling effort, but doesn't fully get the `TypeRegistry` to a place
where it handles all OOMs yet. There are a couple places that need further
work (usage of hash sets and `Cow::into_owned`) which I have marked with `TODO`
comments. In the meantime, I found this to be a nice refactoring of the existing
functionality, so I think it can land as-is.

* review feedback

show more ...

consistently create thread and task when entering component instance (#12379)

* consistently create thread and task when entering component instance

Previously, we weren't creating a new thread or

consistently create thread and task when entering component instance (#12379)

* consistently create thread and task when entering component instance

Previously, we weren't creating a new thread or task in all cases when entering
a component instance, even when component model async features were enabled. In
particular, entering an instance via a sync-to-sync, guest-to-guest adapter, via
`Linker::instantiate[_async]`, or via `[Typed]Func::call` all skipped creating a
thread or task, creating panics and/or instance mismatches in certain cases.

This commit addresses all those cases and also adds assertions to all CM async
intrinsics to verify that the caller instance matches the most-recently-pushed
task. Note that we still skip pushing and popping threads and tasks if no CM
async features are enabled in the `Config`.

In order to populate the `GuestTask::instance` field for tasks created as part
of `Linker::instantiate[_async]` calls, I had to add a
`RuntimeComponentInstanceIndex` field to `GlobalInitializer::InstantiateModule`
and friends so it would be available when needed.

While testing this, I uncovered and fixed a couple of related issues:

- We weren't checking the `may_leave` flag when guest-to-guest calling a resource destructor
- We weren't checking whether a subtask was ready to delete (e.g. that no threads were still running) before attempting to delete it while deleting its supertask

* fix warnings when component-model-async feature disabled

* address review feedback

* push a task when calling a resource dtor host-to-guest

* add tests which call `thread.index` from realloc and post-return functions

...and assert that the indexes match as expected.

Getting the post-return test to pass required moving the call to
`StoreOpaque::exit_sync_call` to after the post-return function is called.

show more ...

Fix `Module::image_range` to include non-text part of module. (#12302)

* Fix `Module::image_range` to include non-text part of module.

This method is informational for embedders to be able to, for

Fix `Module::image_range` to include non-text part of module. (#12302)

* Fix `Module::image_range` to include non-text part of module.

This method is informational for embedders to be able to, for example,
ensure an image in memory is `mlock`'d (not swapped out). In the
refactors around the StoreCode/EngineCode split, I mistakenly redefined
this to only the text section. This is not a Wasm execution correctness
issue but may lead to performance issues if an embedder relies on this
behavior. This PR fixes the definition.

* Components as well as core modules.

* Ignore new tests in miri.

show more ...

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`

Instead of `anyhow::Error`.

This commit re-exports the `wasmtim

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`

Instead of `anyhow::Error`.

This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`
module, updates the prelude to include these new error-handling types, redirects
our top-level `wasmtime::{Error, Result}` re-exports to re-export
`wasmtime::error::{Error, Result}`, and updates various use sites that were
directly using `anyhow` to use the new `wasmtime` versions.

This process also required updating the component macro and wit-bindgen macro to
use the new error types instead of `anyhow`.

Part of https://github.com/bytecodealliance/wasmtime/issues/12069

* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense

* cargo fmt

* Move `crate::error::Thing` to `crate::Thing` where it makes sense

show more ...

Debug: create private code memories per store when debugging is enabled. (#12051)

* Debug: create private code memories per store when debugging is enabled.

This will allow patching code to implem

Debug: create private code memories per store when debugging is enabled. (#12051)

* Debug: create private code memories per store when debugging is enabled.

This will allow patching code to implement e.g. breakpoints. (That is,
for now the copies are redundant, but soon they will not be.)

This change follows the discussion [here] and offline to define a few
types that better encapsulate the distinction we want to enforce.
Basically, there is almost never a bare `CodeMemory`; they are always
wrapped in an `EngineCode` or `StoreCode`, the latter being a per-store
instance of the former. Accessors are moved to the relevant place so
that, for example, one cannot get a pointer to a Wasm function's body
without being in the context of a `Store` where the containing module
has been registered. The registry then returns a `ModuleWithCode` that
boxes up a `Module` reference and `StoreCode` together for cases where
we need both the metadata from the module and the raw code to derive
something.

The only case where we return raw code pointers to the `EngineCode`
directly have to do with Wasm-to-array trampolines: in some cases, e.g.
`InstancePre` pre-creating data structures with references to host
functions, it breaks our expected performance characteristics to make
the function pointers store-specific. This is fine as long as the
Wasm-to-array trampolines never bake in direct calls to Wasm functions;
the strong invariant is that Wasm functions never execute from
`EngineCode` directly. Some parts of the component runtime would also
have to be substantially refactored if we wanted to do away with this
exception.

The per-`Store` module registry is substantially refactored in this PR.
I got rid of the modules-without-code distinction (the case where a
module only has trampolines and no defined functions still works fine),
and organized the BTreeMaps to key on start address rather than end
address, which I find a little more intuitive (one then queries with the
dual to the range -- 0-up-to-PC and last entry found).

[here]: https://github.com/bytecodealliance/wasmtime/pull/12051#pullrequestreview-3493711812

* Review feedback: do not assume a reasonable code alignment; error when it cannot be known

* Review feedback: fail properly in profiler when we are cloning code

* Fix guest-profiler C API.

* Review feedback: make private-code representation impossible in non-debugging-support builds.

* Add TODO comment referencing issue for cloning only .text.

* clang-format

* Review feedback: add back Component::image_range.

* Review feedback: error on registering profiling metadata when debug is enabled.

* rustfmt

* Remove early bail on profiling-data registration when debugging is enabled: this always happens so we cannot error out.

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

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

Remove `AllCallFunc` (#11694)

* Remove `AllCallFunc`

And add `FuncKeyKind` and `FuncKeyNamespace` types.

Split out from https://github.com/bytecodealliance/wasmtime/pull/11630

* fix warning and d

Remove `AllCallFunc` (#11694)

* Remove `AllCallFunc`

And add `FuncKeyKind` and `FuncKeyNamespace` types.

Split out from https://github.com/bytecodealliance/wasmtime/pull/11630

* fix warning and disriminant gap

* add module arg to `Module::new()` calls in tests

show more ...

Package component model options in an index (#11324)

* Package component model options in an index

This commit is a refactoring of how canonical ABI options are handled
during compilation and runti

Package component model options in an index (#11324)

* Package component model options in an index

This commit is a refactoring of how canonical ABI options are handled
during compilation and runtime. Previously options were "exploded"
meaning that options were all passed around as parameters but this was a
bummer for a few reasons:

* This is `unsafe`-prone as options have raw pointers such as memory and
functions. This meant that all functions/operations working with
options were fundamentally `unsafe`.

* This was unwieldy as the set of options continues to grow larger over
time. The `VMLoweringCallee` function previously had 10+ parameters,
most of which were canonical ABI options.

To solve these two problems options are now intern'd at compile time to
an `OptionsIndex`, a 32-bit value. This is stored as a new table in
component metadata and consulted at runtime. This means that
`OptionsIndex` can be passed around with an instance for a much safer
means of threading options around. Additionally there's no need to pass
around all parameters individually and instead just one parameter,
`OptionsIndex`, need be threaded through.

This commit additionally overhauls trampoline generation for the
component compiler to avoid a function-per-intrinsic and instead have a
single function that all intrinsics use. I found this easier to
understand and helps codify that all intrinsics are basically the same
with some minor details differing between them.

The end result of this is (hopefully) a net simplification of the
component compiler in addition to a large amount of removal of `unsafe`
code in the async implementation as only safe types are passed around
now instead of raw pointers.

Closes #10143
Closes #11188

* Fill out some TODO comments

show more ...

Raise `unsafe_op_in_unsafe_fn` further in Wasmtime (#11322)

* Raise `unsafe_op_in_unsafe_fn` further in Wasmtime

Now it's at `wasmtime::runtime`, not just `wasmtime::runtime::vm`.

* Review comments

Enable `allow_attributes_without_reason` (#11195)

* Enable `allow_attributes_without_reason`

This commit enables the `clippy::allow_attributes_without_reason` for
the `wasmtime` crate which previou

Enable `allow_attributes_without_reason` (#11195)

* Enable `allow_attributes_without_reason`

This commit enables the `clippy::allow_attributes_without_reason` for
the `wasmtime` crate which previously forcibly allowed it. The reason
this was allowed was that when the workspace was first migrated the
Wasmtime crate had too many instances that I was willing to fix. I've
now come back around and tried to fix everything.

In short: ideally delete `#[allow]`, otherwise use `#[expect]`,
otherwise use `#[allow]`.

prtest:full

* Adjust some directives

* Fix some warnings

* Fix stack switching size tests on unix

* Don't have a conditional `Drop` impl

* Force `testing_freelist` method to be used

Too lazy to write `#[cfg]`, but not too lazy to write a test.

show more ...

Remove dead `callee` field of vmctx (#11014)

* Remove dead `callee` field of vmctx

This was used long ago but refactorings since then have removed the need
for its existence, so remove it outright.

Remove dead `callee` field of vmctx (#11014)

* Remove dead `callee` field of vmctx

This was used long ago but refactorings since then have removed the need
for its existence, so remove it outright.

* Update test expectations

* Shuffle around some imports

show more ...

Refactor the representation of component::Func (#10914)

* Expand on FIXME comments

In case it takes awhile to get to them...

* Remove `FuncData::types`

This can always be inferred from the insta

Refactor the representation of component::Func (#10914)

* Expand on FIXME comments

In case it takes awhile to get to them...

* Remove `FuncData::types`

This can always be inferred from the instance itself.

* Add an `ExportIndex` to `FuncData`

This will soon be used to remove most other fields, but for now just
have it hanging out there.

* Remove `FuncData::component_instance` field

* Remove `FuncData::post_return`

* Remove `FuncData::ty`

* Remove `FuncData::export`

* Remove `FuncData::options`

* Remove `FuncData::post_return_arg`

This field was moved to `ComponentInstance` as the stateful storage of
the last function return value.

* Refactor the representation of `component::Func`

This commit updates the implementation of `component::Func` to be
index-based like all other exported items are now in Wasmtime. This
necessitated a new `StoreComponentInstanceId` abstraction similar to
`StoreInstanceId`. Additionally the `component_instance_replace`
function was entirely removed as it's no longer necessary.

show more ...

Remove `Stored` usage from `wasmtime::component::Instance` (#10913)

* Remove mutability required on a number of component methods

Powered by previous refactorings it's possible to just take
`&Store

Remove `Stored` usage from `wasmtime::component::Instance` (#10913)

* Remove mutability required on a number of component methods

Powered by previous refactorings it's possible to just take
`&StoreOpaque` in these locations.

* Move core instance map into `ComponentInstance`

This commit moves the mapping from a `RuntimeInstanceIndex` to a
`wasmtime::Instance` from `wasmtime::component::InstanceData` into the
internal `ComponentInstance` structure. This is done in preparation to
remove `InstanceData` eventually.

* Move `Component` to live in `ComponentInstance`

Previously this lived in `InstanceData` but that's just a historical
artifact of the old `wasmtime` and `wasmtime-runtime` split. Nowadays
it's possible to store `Component` directly to further move information
out of `InstanceData`.

* Move `InstanceData::imports` to `ComponentInstance`

More preparation for the removal of `InstanceData` entirely.

* Move lookup functions from `InstanceData` to `ComponentInstance`

More prep for the removal of `InstanceData`.

* Reduce some more reliance on `InstanceState`

Just removing it from some type signatures to make future removal
easier.

* Remove an unused result from a helper function

No caller needs it, so go ahead and remove it.

* Make `ComponentInstance::imports` private

This moves some methods around and documents preexisting `unsafe`
contracts to get this field private and prevent external access to it.

* Remove `InstanceData` from `Instantiator`.

Use `OwnedComponentInstance` instead.

* Remove `InstanceData`, refactor `Instance`

This commit refactors the representation of `component::Instance` to be
purely index-based to data already within a store. This makes creation
of an `Instance` free compared to before where auxiliary data needed to
be created. Note that this doesn't actually change storage within a
`Store<T>` as instances are still there, it's just that now the storage
lives in a non-`Stored`-related location.

show more ...

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

Component and Instance have corresponding get_export, get_export_index (#10597)

* component::Instance: get_export gives a ComponentItem, ExportIndex pair

just like Component::export_index does

* a

Component and Instance have corresponding get_export, get_export_index (#10597)

* component::Instance: get_export gives a ComponentItem, ExportIndex pair

just like Component::export_index does

* align Instance and Component with get_export and get_export_index

* fix example

* component macro expanded: bless output

* fix component model tests

* cli only needs get_export_index

* code review: deduplicate export to typedef transformation into ComponentItem::from_export

show more ...

Guest Profiling suport for component model (#10507)

* Guest Profiling suport for component model

This change adds support for using guest profiling with the
component model. In addition to the cor

Guest Profiling suport for component model (#10507)

* Guest Profiling suport for component model

This change adds support for using guest profiling with the
component model. In addition to the core change to support
attributing stack frames to constituient modules within a component,
the cli `run` and `serve` commands are also updated to support
using the `--profile=guest` cli option with components.

https://github.com/bytecodealliance/wasmtime/issues/8773
https://github.com/bytecodealliance/wasmtime/issues/7669

* fixup! Guest Profiling suport for component model

show more ...

wasmtime-environ: add initial table support (#10497)

* wasmtime-environ: add initial table support

In order to lower the [`thread.spawn_indirect`] canonical builtin from
the component model, we nee

wasmtime-environ: add initial table support (#10497)

* wasmtime-environ: add initial table support

In order to lower the [`thread.spawn_indirect`] canonical builtin from
the component model, we need to be able to refer to the tables exported
from instance. This change adds the initial plumbing to access such
tables.

[`thread.spawn_indirect`]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/CanonicalABI.md#-canon-threadspawn_indirect

* review: add missing doc comment

* review: add missing field calculation

* review: fix a return type

* fix: gate `pub use` behind component-model feature

show more ...

Add Engine/Component::deserialize_raw (#10321)

* Add Engine/Component::deserialize_raw

For targets without virtual memory support, the only mechanism for
load code previously was to copy bytes from

Add Engine/Component::deserialize_raw (#10321)

* Add Engine/Component::deserialize_raw

For targets without virtual memory support, the only mechanism for
load code previously was to copy bytes from a provided slice into
a separate, owned, allocated buffer containing a copy of the serialized
module contents. This is expensive for constrained targets and
prohibits embedded runtimes like doing things like running code
directly out of memory-mapped devices such as NOR flash.

The tradeoff for directly using the externally owned memory is that
the caller must ensure that the code memory will not be written
to for the lifetime of the CodeMemory.

Loading code from externally owned memory is supported for all
configurations but is expected to fail to deserialize on platforms
that suport virtual memory and are attempting to load modules
or components that require that the memory be made executable
(native code rather than pulley).

https://github.com/bytecodealliance/wasmtime/issues/10245

* Fix tests for s390x

Previously, there was a bad assumption that pulley32/64 were the
only targets but there's also the "be" variants. Use the
`pulley_host` helper to better get the right pulley target
for the host.

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

Provenance preparation for Pulley (#10043)

* Provenance preparation for Pulley

This commit is an internal refactoring of Wasmtime's runtime to prepare
to execute Pulley in MIRI. Currently today th

Provenance preparation for Pulley (#10043)

* Provenance preparation for Pulley

This commit is an internal refactoring of Wasmtime's runtime to prepare
to execute Pulley in MIRI. Currently today this is not possible because
Pulley does not properly respect either strict or permissive provenance
models. The goal of this refactoring is to enable fixing this in a
future commit that doesn't touch everything in the codebase. Instead
everything is touched here in this commit.

The basic problem with Pulley is that it is incompatible with the strict
provenance model of Rust which means that we'll be using "exposed
provenance" APIs to satisfy Rust's soundness requirements. In this model
we must explicitly call `ptr.expose_provenance()` on any pointers
which are exposed to compiled code. Arguably we should also be already
doing this for natively-compiled code but I am not certain about how
strictly this is required.

Currently in Wasmtime today we call `ptr.expose_provenance()` nowhere.
It also turns out, though, that we share quite a few pointers in quite a
few places with compiled code. This creates a bit of a problem! The
solution settled on in this commit looks like:

* A new marker trait, `VmSafe`, is introduced. This trait is used to
represent "safe to share with compiled code" types and enumerates some
properties such as defined ABIs, primitives wrappers match primitive
ABIs, and notably "does not contain a pointer".

* A new type, `VmPtr<T>`, is added to represent pointers shared with
compiled code. Internally for now this is just `SendSyncPtr<T>` but in
the future it will be `usize`. By using `SendSyncPtr<T>` it shouldn't
actually really change anything today other than requiring a lot of
refactoring to get the types to line up.

* The core `vmctx_plus_offset*` methods are updated to require
`T: VmSafe`. Previously they allowed any `T` which is relatively
dangerous to store any possible Rust type in Cranelift-accessible
areas.

These three fundamental changes were introduced in this commit. All
further changes were refactoring necessary to get everything working
after these changes. For example many types in `vmcontext.rs`, such as
`VMFuncRef`, have changed to using `VmPtr<T>` instead of `NonNull<T>` or
`*mut T`. This is a pretty expansive change which resulted in touching a
lot of places.

One premise of `VmPtr<T>` is that it's non-null. This was an
additional refactoring that updated a lot of places where previously
`*mut T` was used and now either `VmPtr<T>` or `NonNull<T>` is used.

In the end the intention is that `VmPtr<T>` is used whenever pointers
are store in memory that can be accessed from Cranelift. When operating
inside of the runtime `NonNull<T>` or `SendSyncPtr<T>` is preferred
instead.

As a final note, no provenance changes have actually happened yet. For
example this doesn't fix Pulley in MIRI. What it does enable, though, is
that the future commit to fix Pulley in MIRI will be much smaller with
this having already landed.

* Run the full test suite in PR CI

prtest:full

* Minor CI issues

* Fix no_std build

* Fix miri build

* Don't use `VmPtr` in FFI function signatures

Use `NonNull` or `*mut u8` as appropriate for function signatures
instead. It shouldn't be required to use `VmPtr` during the handoff to
compiled code as we've already annotated the pointer going out.

* Fix rebase conflict

* Review comments

show more ...

async/stream/future plumbing for wasmtime-environ (#10047)

* async/stream/future plumbing for wasmtime-environ

I've split this out of #9582 to make review easier.

This patch includes the plumbing

async/stream/future plumbing for wasmtime-environ (#10047)

* async/stream/future plumbing for wasmtime-environ

I've split this out of #9582 to make review easier.

This patch includes the plumbing needed to route
async/stream/future/error-context data from `wit-parser`, through the various
layers of `wasmtime-environ`, and on to `wasmtime-cranelift` and `wasmtime`.
The `wasmtime::runtime`, `wasmtime_environ::fact`, and
`wasmtime_cranelift::compiler::component` modules only contain `todo!()` stubs
to begin with; I'll flesh those out in later PRs.

Signed-off-by: Joel Dice <[email protected]>

remove debugging code

Signed-off-by: Joel Dice <[email protected]>

revert comment formatting change in trap_encoding.rs

Signed-off-by: Joel Dice <[email protected]>

deduplicate code in inline.rs

Signed-off-by: Joel Dice <[email protected]>

remove `ComponentTypesBuilder::error_context_type`

This was just an alias for `error_context_table_type`, which I've made public.

Signed-off-by: Joel Dice <[email protected]>

defer `VMComponentOffsets` changes to a future PR

Signed-off-by: Joel Dice <[email protected]>

* fix fuzz build

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>

show more ...