Rename our OOM-handling `Vec` to `TryVec` (#12721)

* Rename our OOM-handling `Vec` to `TryVec`

* fix tests that got mangled by the LSP server

* fix more tests mangled by LSP

Rename our OOM-handling `String` to `TryString` (#12720)

Add support for fine-grained operator costs (#11572) (#12541)

Introduce `OperatorCostStrategy` and `OperatorCost` to allow configuring
per-operator fuel costs via `Config::operator_cost`. Previously

Add support for fine-grained operator costs (#11572) (#12541)

Introduce `OperatorCostStrategy` and `OperatorCost` to allow configuring
per-operator fuel costs via `Config::operator_cost`. Previously, operator
costs were hardcoded inline in both Cranelift and Winch code generation.
Now the cost logic is centralized in `wasmtime-environ` and referenced
from both backends via `tunables.operator_cost.cost(op)`.

`OperatorCostStrategy` is an enum with two variants:
- `Default`: reproduces the original hardcoded behavior (nop/drop/control
flow cost 0, everything else costs 1).
- `Table(Box<OperatorCost>)`: a per-operator cost table generated via
`wasmparser::for_each_operator!`.

Because `OperatorCostStrategy::Table` contains a `Box`, the type has a
destructor. This makes `Tunables` non-trivially droppable, which prevents
using the `..Tunables::default_miri()` functional update syntax in const
functions (E0493). To work around this, `default_miri`, `default_u32`,
and `default_u64` are changed to non-const fns. None of
these are called in const contexts, except in tests.

show more ...

Use OOM-handling collections for `Metadata` (#12608)

* Use OOM-handling collections for `Metadata`

These are created in the compiler, where we don't need to worry about OOM, but
are deserialized in

Use OOM-handling collections for `Metadata` (#12608)

* Use OOM-handling collections for `Metadata`

These are created in the compiler, where we don't need to worry about OOM, but
are deserialized in the "data-plane" where we do. The OOM-handling collections'
`Deserialize` implementations automatically handle OOM for us here.

* fix serialization unit tests

show more ...

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

Use low-level ELF-parsing APIs when checking engine compatibility (#12551)

These low-level APIs do not allocate and should generally be more efficient,
since they are avoiding unnecessary work.

Config knobs and validation for record-replay (#12375)

Refactor how concurrency support is enabled in a `Store` (#12416)

* Document panics from using CM async machinery when CM async is not enabled

* Refactor how concurrency support is enabled in a `St

Refactor how concurrency support is enabled in a `Store` (#12416)

* Document panics from using CM async machinery when CM async is not enabled

* Refactor how concurrency support is enabled in a `Store`

This commit is an extension/refactor of #12377 and #12379. Notably this
decouples the runtime behavior of Wasmtime from enabled/disabled
WebAssembly proposals. This enables the `wasmtime serve` subcommand, for
example, to continue to disallow component-model-async by default but
continue to use `*_concurrent` under the hood.

Specifically a new `Config::concurrency_support` knob is added. This is
plumbed directly through to `Tunables` and takes over the preexisting
`component_model_concurrency` field. This field configures whether
tasks/etc are enabled at runtime for component-y things. The default
value of this configuration option is the same as `cfg!(feature =
"component-model-async")`, and this field is required if
component-model-async wasm proposals are enabled. It's intended that
eventually this'll affect on-by-default wasm features in Wasmtime
depending if the support is compiled in.

This results in a subtle shift in behavior where component-model-async
concurrency is used by default now because the feature is turned on by
default, even though the wasm features are off-by-default. This required
adjusting a few indices expected in runtime tests due to tasks/threads
being allocated in index spaces.

Finally, this additionally denies access at runtime to
`Linker::*_concurrent` when concurrent support is disabled as otherwise
the various runtime data structures won't be initialized and panics will
happen.

Closes #12393

* Add a `-Wconcurrency-support` CLI flag

Used to update disas tests to show that, when disabled, old codegen
quality is preserved

* Ungate `Config` flag

* Review comments

---------

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

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