| 37c49428 | 30-Mar-2026 |
Alex Crichton <[email protected]> |
Fix a panic in `Bytes{,Mut}` `StreamProducer` impls (#12878)
This commit fixes the logic of these `impl`s to match the `Vec`-style
blocks to relinquish the entire buffer to Wasmtime immediately. Thi
Fix a panic in `Bytes{,Mut}` `StreamProducer` impls (#12878)
This commit fixes the logic of these `impl`s to match the `Vec`-style
blocks to relinquish the entire buffer to Wasmtime immediately. This
fixes an issue where `split_off` is called with too large a value which
can panic.
show more ...
|
| 34caf681 | 10-Mar-2026 |
Marco Neumann <[email protected]> |
refactor: clarify error msg. for de-allocated `ResourceAny` (#12751)
* test: illustrate #12465
* refactor: clarify error msg. for de-allocated `ResourceAny`
The error message used to state that th
refactor: clarify error msg. for de-allocated `ResourceAny` (#12751)
* test: illustrate #12465
* refactor: clarify error msg. for de-allocated `ResourceAny`
The error message used to state that this happens because the type of
the resource changed, but actually this can also happen with the very
same type if the resource was already de-allocated. Clarifying the error
message might safe some `wasmtime` users some long debugging sessions.
See #12465.
show more ...
|
| 1b59b579 | 09-Mar-2026 |
Yordis Prieto <[email protected]> |
Add support for map type (#12216)
* Add support for map type
Signed-off-by: Yordis Prieto <[email protected]>
* Add Map and MapEntry classes to support key/value pairs in component model
Th
Add support for map type (#12216)
* Add support for map type
Signed-off-by: Yordis Prieto <[email protected]>
* Add Map and MapEntry classes to support key/value pairs in component model
This commit introduces the Map and MapEntry classes, enabling the representation of map values in the component model. The Map class allows for the creation and iteration of key/value pairs, enhancing the functionality of the wasmtime component API. Additionally, the .gitignore file is updated to exclude build artifacts from the crates/c-api directory.
* Add wasm_component_model_map configuration support
* Format code
* Format C code
* Enhance component model to support HashMap<K, V> type
This commit introduces support for HashMap<K, V> in the component model, allowing maps to be represented as list<tuple<K, V>> in the canonical ABI. It includes implementations for the ComponentType, Lower, and Lift traits for HashMap, enabling type checking, lowering to flat representations, and lifting from memory. Additionally, the maximum depth for type generation in the fuzzing utility is updated to accommodate the new map type.
* Refactor component configuration to introduce map support
This commit removes the previous wasm features configuration and adds new functions for creating a map-configured engine. The `map_config` and `map_engine` functions are introduced to facilitate the use of the component model with maps in tests, ensuring that the engine is properly configured for map types in the component model.
* Add new WAST test for map types and remove map type definitions from existing tests
This commit introduces a new WAST test file specifically for testing various map types in the component model. Additionally, it removes the redundant map type definitions from the existing types.wast file to streamline the test suite.
* Update component fuzzing and dynamic tests to replace call_and_post_return with call
* Format code
* Refactor HashMap usage in typed.rs to use wasmtime_environ collections
* Fix HashMap initialization and insertion to handle potential errors in typed.rs
* Refactor HashMap handling in typed.rs to use lower_map_iter for improved iteration and memory management. Introduce new implementations for ComponentType, Lower, and Lift traits for std::collections::HashMap, enhancing support for map types in the component model.
* Fix map adapter trampoline compilation and alignment bugs
The translate_map function had two categories of bugs preventing map
adapter trampolines from working:
1. Wasm stack discipline: local_set_new_tmp emits LocalSet which pops
from the stack, but was called when the stack was empty (to
"pre-allocate" locals). Fixed by computing values first, then
calling local_set_new_tmp to consume them—matching translate_list's
pattern. Also removed an erroneous LocalTee that left an orphan
value on the stack. Affected: src_byte_len, dst_byte_len,
cur_src_ptr, cur_dst_ptr.
2. Pointer advancement: after value translation, the pointer still
points at the value start. The code only advanced by trailing
padding instead of value_size + trailing_padding, causing every
loop iteration to re-read the same memory.
Also fixes entry layout to use proper record alignment rules (entry
align = max(key_align, value_align), value at aligned offset).
* Refactor map entry layout calculations to use canonical ABI
* Remove unnecessary clone of map pairs during lowering
Val::Map already holds Vec<(Val, Val)> which derefs to &[(Val, Val)],
matching lower_map's signature directly. The intermediate Vec allocation
and deep clone of every key/value pair was redundant.
* Deduplicate map lift logic between HashMap implementations
* Deduplicate list and map sequence translation scaffolding
* Fix cargo fmt formatting issues
* Deduplicate map typecheck logic
* Deduplicate map lowering with linear_lower_map_to_flat and linear_lower_map_to_memory helpers
* Clean up lift_try_map: use drop, move TryHashMap import to module scope
* Fix CI: arbtest overflow and no-std HashMap lift_map
- component_fuzz: use saturating_sub in generate_hashable_key to prevent
underflow when fuel is 0 and Enum variant is chosen
- typed: remove incorrect ? operators in lift_map for hashbrown::HashMap
(with_capacity and insert don't return Result)
* Store map tuple layout in TypeMap
Compute map entry ABI and value offsets once during type building, and reuse that metadata in runtime map lift/lower paths instead of recalculating tuple layout at each call site.
* Refactor map ABI argument passing
Bundle map lift/lower layout and type metadata into a small MapAbi32 helper so map helper calls stay concise without changing behavior.
* Fix CI: enable component_model_map in fuzzing and handle map in arbitrary_val
The fuzzer's component_api oracle was generating map types but the engine
didn't have the map feature enabled, and arbitrary_val had no arm for
Type::Map. Enable component_model_map in the store helper (matching how
component_model_async is forced on) and implement arbitrary value generation
for map types.
---------
Signed-off-by: Yordis Prieto <[email protected]>
show more ...
|
| 8de60f18 | 02-Mar-2026 |
Jelle van den Hooff <[email protected]> |
Fix async stream cancel corrupting read/write state (#12704)
When `stream.cancel-read` or `stream.cancel-write` is called with the
`async` option and the cancel cannot complete immediately (returns
Fix async stream cancel corrupting read/write state (#12704)
When `stream.cancel-read` or `stream.cancel-write` is called with the
`async` option and the cancel cannot complete immediately (returns
BLOCKED), the code was unconditionally transitioning the read/write
state from GuestReady to Open. This destroyed the buffer address/count
info stored in GuestReady, causing incorrect behavior when the host
producer/consumer later tried to access the stream state.
Guard the GuestReady -> Open state transition with a check that the
cancel did not return BLOCKED. When blocked, the cancel is still
in-flight and the read/write state must be preserved until the cancel
completes.
Adds a regression test that creates a host StreamProducer, starts an
async read (BLOCKED), then async-cancels (BLOCKED), and waits for
cancel completion.
show more ...
|
| da093747 | 02-Mar-2026 |
Alex Crichton <[email protected]> |
Relax panics in async/futures to traps/errors (#12688)
* Relax panics in async/futures to traps/errors
This commit is an admittance that I don't believe we're going to get
to a point where we are c
Relax panics in async/futures to traps/errors (#12688)
* Relax panics in async/futures to traps/errors
This commit is an admittance that I don't believe we're going to get
to a point where we are confident enough in the fuzzing of
component-model-async such that we could confidently say we're
exercising the vast majority of possible panics. Development of
component-model-async has shown a steady trickle of panics over the
course of the development of the feature, and this trend has been
persistent over time as well.
An attempt was made in #12119 to add a fuzzer dedicated to async events
but that didn't actually find anything in development and it has missed
a number of panics present before and discovered after its introduction.
Overall I do not know how to improve the fuzzer to the point that it
would find pretty much all of the existing async-related panics over
time.
To help address this concern of the `concurrent.rs` implementation this
commit goes through and replaces things like `unwrap()`, `assert!`,
`panic!`, and `unreachable!` with an error-producing form. The benefit
of this is that a bug in the implementation is less likely to result in
a panic and instead just results in a non-spec-compliant trap. The
downside of doing this though is that it can become unclear what errors
are "first class traps", or expected to be guest reachable, and which
are expected to be bugs in Wasmtime. To help address this I've performed
a few refactorings here as well.
* Some traps previously present as error strings are now promoted to
using `Trap::Foo` instead. This has some refactoring of the Rust/C
side as well to make it easier to define new variants. Tests were
additionally added for any trap messages that weren't previously
tested as being reachable.
* A new `bail_bug!` macro was added (internally) for Wasmtime. This is
coupled with a concrete `WasmtimeBug` error type (exported as
`wasmtime::WasmtimeBug`). The intention is that `bail!` continues to
be "here's a string and I'm a bit too lazy to make a concrete error"
while `bail_bug!` indicates "this is a bug in wasmtime please report
this if you see it".
The rough vision is that if an error condition is reached, and the system
is not broken in such a way that panicking is required, then `bail_bug!`
can be used to indicate a bug in Wasmtime as opposed to panicking. This
reduces the real-world impact of hitting these scenarios by downgrading a
CVE-worthy `panic!` into a bug-worthy non-spec-compliant trap. Not all
panics are able to be transitioned to this as some are load bearing from
a safety perspective or similar (or indicate something equally broken),
but the vast majority of cases are suitable for "return a trap, lock
down the store, and let destructors take care of everything else".
This change additionally has resulted in API changes for `FutureReader`
and `StreamReader`. For example creation of these types now returns a
`Result` for when the `ResourceTable` is full, for example, instead of
panicking.
* Fix CI build
* Translate `WasmtimeBug` to panics in debug mode
* Review comments
* Refactor some stream methods for fewer panics
show more ...
|
| 3764e757 | 10-Feb-2026 |
Alex Crichton <[email protected]> |
Refactor borrow state tracking for async tasks (#12550)
* Refactor borrow state tracking for async tasks
This commit is a somewhat deep refactoring of how the state of
`borrow<T>` is managed for b
Refactor borrow state tracking for async tasks (#12550)
* Refactor borrow state tracking for async tasks
This commit is a somewhat deep refactoring of how the state of
`borrow<T>` is managed for both the host and the guest with respect to
async tasks. This additionally refactors how some async task management
is done for host-called functions.
The fundamental problem being tackled here is #12510. In that issue it
was discovered that the way `CallContext`, the borrow tracking mechanism
in Wasmtime, is managed is incompatible with async tasks. Specifically
the previous assumption of the scope being mutated for a borrow is
somewhere on the call stack is no longer true. It's possible for an
async task to be suspended, for example, and then a sibling task drops a
borrow which should update the scope of the suspended task. There were a
number of other small issues I noticed here and there which this PR
additionally has tests for, all of which failed before this change and
pass afterwards.
The manner in which borrow state is manipulated is a pretty old part of
the component model implementation dating back to the original
implementation of resources. I decided to forgo any possible quick fix
and have attempted to more deeply refactor and integrate async tasks
into all of this infrastructure. A list of the changes made here are:
* The `CallContexts` structure, a stack of `CallContext`, was removed.
Tasks now directly store a `CallContext` which is the source of truth
for borrow tracking for that call, and it does not move from this
location. The store `CallContexts` is now deleted in favor of updating
the `Option<ConcurrentState>` in the store to be an `enum` of either
concurrent state or a stack. In this manner the old stack-based
structure is still used sometimes, but it's impossible to reach when
concurrency is enabled.
* Entry to the host from guests now reliably pushes a `HostTask` into
the store. Previously where a frame were always pushed into a
`CallContext` a `HostTask` is pushed into the store. This is still
expected to be a bit too expensive for cheap host calls, but it
doesn't meaningfully change the performance profile of before.
* The `resource_enter_call` and `resource_exit_call` libcalls have been
removed. These are now folded into the `enter_sync_call` and
`exit_sync_call` libcalls. Emission of these hooks has been updated
accordingly. The concept of entering a call more generally has been
removed. This is more formally known in the async world as a task
starting, so the task creation is now responsible for the demarcation
of entering a call. Additionally this means that the concept of
exiting a call has somewhat gone away. Instead this method was renamed
to `validate_scope_exit` which double-checks that a borrow-scope can
be exited but doesn't actually remove the task. Task removal is
deferred to preexisting mechanisms.
* Management of a `GuestTask`'s previous `Option<CallContext>` field,
for example taking/restoring and pushing/popping onto `CallContexts`
is now all gone. All related code is outright deleted as the
`GuestTask`'s now non-optional `CallContext` field is the source of truth.
* The `ConcurrentState` structure now stores a `CurrentThread` enum
instead of `Option<QualifiedThreadId>`. This represents how the
currently executing thread could be a host thread, not just a guest
thread, which is required for borrow-tracking.
* `HostTask` creation in `poll_and_block` and `first_poll`, the two main
entrypoints of async host tasks when called by the guest, is now
externalized from these functions. Instead these functions assume that
the currently running thread is already a `HostTask` of some kind.
* In `poll_and_block` the host's result is no longer stored in the guest
task but in the host task instead.
Overall this enables the `*.wast` test for #12510 to fix the original
issue. This then adds new tests to ensure that cleanup of various
constructs happens appropriately, such as cancelling a host task should
clean up its associated resources. Additionally synchronously calling an
async host task no longer leaks resources in a `Store` and should
properly clean up everything.
There is still more work to do in this area (e.g. #12544) but that's
going to be deferred to a future PR at this point.
Closes #12510
prtest:full
* Review comments/CI fixes
show more ...
|
| cc8d04f4 | 23-Jan-2026 |
Alex Crichton <[email protected]> |
Remove need for explicit `Config::async_support` knob (#12371)
* Refactor component model host function definitions
Push the `async`-ness down one layer.
* Remove need for explicit `Config::async
Remove need for explicit `Config::async_support` knob (#12371)
* Refactor component model host function definitions
Push the `async`-ness down one layer.
* Remove need for explicit `Config::async_support` knob
This commit is an attempt to step towards reconciling "old async" and
"new async" in Wasmtime. The old async style is the original async
support in Wasmtime with `call_async`, `func_wrap_async`, etc, where the
main property is that the store is "locked" during an async operation.
Put another way, a store can only execute at most one async operation at
a time. This is in contrast to "new async" support in Wasmtime with the
component-model-async (WASIp3) support, where stores can have more than
one async operation in flight at once.
This commit does not fully reconcile these differences, but it does
remove one hurdle along the way: `Config::async_support`. Since the
beginning of Wasmtime this configuration knob has existed to explicitly
demarcate a config/engine/store as "this thing requires `async` stuff
internally." This has started to make less and less sense over time
where the line between sync and async has become more murky with WASIp3
where the two worlds comingle. The goal of this commit is to deprecate
`Config::async_support` and make the function not actually do anything.
In isolation this can't simply be done, however, because there are many
load-bearing aspects of Wasmtime that rely on this `async_support` knob.
For example once epochs + yielding are enabled it's required that all
Wasm is executed on a fiber lest it hit an epoch and not know how to
yield. That means that this commit is not a simple removal of
`async_support` but instead a refactoring/rearchitecting of how async is
used internally within Wasmtime. The high-level ideas within Wasmtime
now are:
* A `Store` has a "requires async" boolean stored within it.
* All configuration options which end up requiring async, such as
yielding with epochs, turn this boolean on.
* Creation of host functions which use async
(e.g. `func_wrap_{async,concurrent}`) will also turn this option on.
* Synchronous API entrypoints into Wasmtime ensure that this boolean is
disabled.
* Asynchronous APIs are usable at any time.
This means that the concept of an async store vs a sync store is now
gone. All stores are equally capable of executing sync/async, and the
change now is that dynamically some stores will require that async is
used with certain configuration. Additionally all panicking conditions
around `async_support` have been converted to errors instead. All
relevant APIs already returned an error and things are murky enough now
that it's not necessarily trivial to get this right at the embedder
level. In the interest of avoiding panics all detected async mismatches
are now first-class `wasmtime::Error` values.
The end result of this commit is that `Config::async_support` is a
deprecated `#[doc(hidden)]` function that does nothing. While many
internal changes happened as well as having new tests for all this sort
of behavior this is not expected to have a great impact on external
consumers. In general a deletion of `async_support(true)` is in theory
all that's required. This is intended to make it easier to think about
async/sync/etc in the future with WASIp3 and eventually reconcile
`func_wrap_async` and `func_wrap_concurrent` for example. That's left
for future refactorings however.
prtest:full
* Review comments
* Fix CI failures
show more ...
|