|
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7 |
|
| #
9661ca85 |
| 30-Mar-2026 |
Alex Crichton <[email protected]> |
Remove some more panics in `concurrent.rs` (#12874)
Downgrade some panics to `bail_bug!` or `?` where appropriate by propagating `Result<T>` in a few more locations.
|
|
Revision tags: v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6 |
|
| #
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 ...
|
|
Revision tags: v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0 |
|
| #
cb97ae85 |
| 11-Dec-2025 |
Joel Dice <[email protected]> |
allow recursive Wasm invocation from concurrent host functions (#12152)
* allow recursive Wasm invocation from concurrent host functions
The core changes here are:
- remove an unnecessary assertio
allow recursive Wasm invocation from concurrent host functions (#12152)
* allow recursive Wasm invocation from concurrent host functions
The core changes here are:
- remove an unnecessary assertion from `concurrent::prepare_call` - track instance states (e.g. backpressure, etc.) on a per `(Instance, RuntimeComponentInstanceIndex)` basis - both parts of that key are needed now that concurrent state is tracked on a per-store basis rather than a per-instance basis since `RuntimeComponentInstanceIndex`es are not globally unique
While discussing the above with Alex, we realized the use of a `HashMap` to track per-instance states was both pessimal and unnecessary. Consequently, I've folded that state into `ComponentInstance::instance_handle_tables`, renaming it to `instance_states`. That involved a fair amount of code churn, but doesn't change behavior except as described in the second bullet point above.
Thanks to Alex for the test case!
Fixes #12098
Co-authored-by: Alex Crichton <[email protected]> Signed-off-by: Joel Dice <[email protected]>
* use new `RuntimeInstance` type instead of tuples
Signed-off-by: Joel Dice <[email protected]>
---------
Signed-off-by: Joel Dice <[email protected]> Co-authored-by: Alex Crichton <[email protected]>
show more ...
|
|
Revision tags: v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2 |
|
| #
8fbe4c2c |
| 06-Oct-2025 |
Alex Crichton <[email protected]> |
Fix some panics compiling components and resources (#11798)
In working on bytecodealliance/wasm-tools#2335 I found that there's a few test cases in wasm-tools which Wasmtime was panicking to compile
Fix some panics compiling components and resources (#11798)
In working on bytecodealliance/wasm-tools#2335 I found that there's a few test cases in wasm-tools which Wasmtime was panicking to compile. The issues were all related to resource types and how information wasn't registered ahead of time before it was translated from wasmparser's representation to Wasmtime's representation. The high-level cause for this had to do with how component and instance types are handled, as opposed to concrete components or instances themselves. This was effectively a hole in Wasmtime's translation process for components which has never been filled out since the original implementation of resources. The reason that this never came up before is:
* Most components don't currently import or export a component itself. * Most components don't currently import or export component or instance types (as opposed to values).
One of these was required to trigger this issue. The solution implemented in this commit is to plumb the concept of an "abstract resource" which is part of a type but not actually ever used at runtime except for type equality during type reflection. This is expected to have little-to-no impact on real-world components given that these situations are rarely occurring.
show more ...
|
|
Revision tags: v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0 |
|
| #
e8189549 |
| 12-Aug-2025 |
Joel Dice <[email protected]> |
use a single table per instance for resources, waitables, etc. (#11374)
* use a single table per instance for resources, waitables, etc.
Per https://github.com/WebAssembly/component-model/pull/513,
use a single table per instance for resources, waitables, etc. (#11374)
* use a single table per instance for resources, waitables, etc.
Per https://github.com/WebAssembly/component-model/pull/513, the spec now puts resources, waitables, waitable sets, subtasks, and error contexts in the same table per instance. This updates the implementation to match.
- Combine the `ResourceTable` and `StateTable` data structures into a single `HandleTable` structure
- Rename `ComponentInstance::instance_resource_tables` to `instance_handle_tables`
- Remove `ConcurrentState::waitable_tables` and `error_context_tables` in favor of the above
- Move various associated functions from `ConcurrentState` to `ComponentInstance` so they can access `instance_resource_tables`
While I was doing table-related things, I also updated `concurrent::Table::new` to reserve the zero handle to mean "invalid". This won't affect what the guest sees in any way, but it allows us to use `TableId::new(0)` to invalidate host-owned handles in e.g. `{Stream,Future}{Reader,Writer}::close`.
Fixes #11189
Signed-off-by: Joel Dice <[email protected]>
Re-internalize `ResourceKind` to `mod handle_table`
Remove `ResourceKind`
Start flattening the representation of `Slot`
Internalize `get_mut_handle_by_index`
Internalize implementation details such as the representation of slots to and make methods a bit more targeted in their functionality.
Internalize more details of `HandleTable`
Don't expose `HandleKind` and of per-function methods for operating on the various kinds of handles that reside in the table.
Flatten the representation of `Slot`
There's still some more work to do for host/guest resource handles, but this helps realize the goal of the previous refactorings in the meantime.
* stop using `HandleTable::reps_to_indexes` when delivering events
Per review feedback, we'd like to get rid of `HandleTable::reps_to_indexes` entirely. This commit doesn't go quite that far, but now we only use it for `error-context` handles. For waitables, which can only be referenced by at most one guest at a time, we now store the guest handle in `WaitableCommon::handle` and retrieve it from there when delivering an event for that waitable.
For `error-context` handles, the spec requirement that we always lower the same handle for the same `error-context`, combined with the fact that an `error-context` may be referenced by more than one component instance at a time, means we still need some general way to convert a host rep plus component index into a handle. Going forward, we could consider either removing that "same handle" requirement from the spec or consider an alternative implementation (e.g. storing a `HashMap<RuntimeComponentIndex, usize>` in the `ErrorContext` host state for keeping track of the handles for each referencing instance.
Signed-off-by: Joel Dice <[email protected]>
* remove `HandleTable::reps_to_indexes`
Turns out the spec no longer requires that guests receive the same handle for a given `error-context` as the one they already have, so we no longer need this field -- nor do we need to maintain a per-component-instance reference count.
Signed-off-by: Joel Dice <[email protected]>
---------
Signed-off-by: Joel Dice <[email protected]>
show more ...
|
|
Revision tags: v35.0.0, v24.0.4, v33.0.2, v34.0.2 |
|
| #
b221fca7 |
| 03-Jul-2025 |
Joel Dice <[email protected]> |
update `component-model-async` plumbing (#11123)
* [DO NOT MERGE] update `component-model-async` plumbing
This pulls in the latest Component Model async ABI code from the `wasip3-prototyping` repo,
update `component-model-async` plumbing (#11123)
* [DO NOT MERGE] update `component-model-async` plumbing
This pulls in the latest Component Model async ABI code from the `wasip3-prototyping` repo, including various API refactors and spec updates.
This includes all the changes to the `wasmtime` crate from `wasip3-prototyping` _except_ that the `concurrent` submodule and child submodules contain only non-functional stubs. For that reason, and the fact that e.g. `Func::call_async` is now implemented in terms of `Func::call_concurrent`, most of the component model tests are failing. This commit is not meant to be merged as-is; a follow-up commit (to be PR'd separately) will contain the real `concurrent` implementation, at which point the tests will pass again. I'm splitting these into separate PRs to make review easier.
Signed-off-by: Joel Dice <[email protected]>
* Undo wit-bindgen changes
No longer necessary after other refactors
* Move back to crates.io-based wit-bindgen
* Undo upgrade of http-body-util
(deferred for future PR)
* Add back in arbitrary use of async
Looks like it may have been lost by accident
* Make imports more conventional for Wasmtime
* Some minor changes
* Privatize a component field
* Cut down a bit on #[cfg]
* Undo a no-longer-necessary `pub`
* add doc comments for `{Future,Stream,ErrorContext}Any`
Signed-off-by: Joel Dice <[email protected]>
* rename `concurrent` stub module to `concurrent_disabled`
...and avoid panicking in the stubs.
Signed-off-by: Joel Dice <[email protected]>
* fix test regression
Signed-off-by: Joel Dice <[email protected]>
* revert `call_async` and `post_return_impl` changes
These will need to wait until the `component-model-async` feature is fully implemented.
Signed-off-by: Joel Dice <[email protected]>
* remove unused struct
Signed-off-by: Joel Dice <[email protected]>
* add `Options::callback` field
This isn't used yet, but will be used when the real `component-model-async` implementation is merged.
Signed-off-by: Joel Dice <[email protected]>
* Remove no-longer-needed feature
* Trim reexports from Wasmtime
Some of these are no longer needed or can be avoided with small changes. Some deps are likely needed in the next commit but they'll be best added there.
* Update test expectations
* More trimming of Cargo.toml
* Defer `*Buffer` traits to next PR
Not needed for this PR I believe.
* Use conventional Wasmtime imports + remove dummy_waker
* Reduce duplication in `*_disabled`
* Remove some unncessary bounds
* Remove some `for<'a>` bounds where unnecessary
* Remove another bound
* Defer more functions to the next PR
`drop_fibers` is different in the next PR, so defer it to then.
* Remove some reexports no longer necessary
Bindings generation changed awhile back so these aren't needed, defer the implementations to the next PR.
* Remove unnecessary drop
This was already moved to `run_manual_drop_routines`
* Defer a `pub(crate)` to a future PR
* Expand comments in traphandlers
* Defer some types to the next PR
* Update linker documentation
* Add `Send`/`Sync` bounds to `ComponentType`
This commit is extracted from from review of #11123 and #11127. While not literally present in those PRs it's my own personal conclusion that it's best to just go ahead and add these bounds at the "base" of the component trait hierarchy. The current implementation in #11123 adds bounds in many locations and this would remove the need to add bounds everywhere and instead have everything inherited through the `Lift` and `Lower` traits.
This raises the question of: why? The main conclusion that I've reached leading to this change is that Wasmtime currently will store `R`, a return value, on the stack during the lowering process back into linear memory. This might involve allocation, however, meaning that wasm can be invoked and a context switch could happen. For Wasmtime's `unsafe impl` of `Send` and `Sync` on fibers to be sound it requires that this stack-local variable is also `Send` and `Sync` as it's an entirely user-provided type. Thus I've concluded that for results it's always required for these to be both `Send` and `Sync` (or at the very least, `Send`).
Given that I've gone ahead and updated to require both `Send` and `Sync` for both params and results. This is not expected to actually have any impact in practice since all primitives are already `Send`/`Sync` (minus `Rc` impls all removed here) and all `bindgen!`-generated types are compositions of `Send`/`Sync` primitives meaning that they're also `Send` and `Sync`.
* Remove some now-unnecessary bounds
* Fix build after #11160
* Remove some now-unnecessary duplicate bounds
* Uncomment test that now works
* Undo accidental doc wrap
* Clarify comment on `Value` types
Don't leave `TODO` in public-facing documentation ideally
* Actually resolve the conflict (forgot to commit)
* Avoid returning boxed futures in APIs
* Defer making constructors more public to a future PR
* Make a method name more conventional
* Refactor `linear_lift_into_from_memory`
* Drop the `max_count` parameter in favor of slicing the `WasmList` itself. Avoids situations such as what happens if `max_count` is larger than the length of the list. * Don't have the default implementation collect to a vector and then push all that onto a different vector. Instead push each item individually through `extend`.
* De-indent a block of code added
* Remove unsafety from `prepare_call`
Mostly move the parameters themselves to the closure to avoid raw pointers/drop/etc.
This will have the consequence of in the future `call_async` is going to now require `Params: 'static` but that seems more-or-less inevitable at this point.
* Go back to returning box, alas.
* Apply same treatment to lift function
Make it a closure and reduce some levels of indirection of the various functions in play.
* Refactor `lower_params` to require less context.
Relax the bounds on the closure specified since it's immediately called and then additionally take out parameters/captures that the closure can carry itself.
* Don't pass extraneous `Instance` parameter
This can now be inferred from `Func`.
* Clean up some SAFETY comments
* Generalize the signature of `lift_results`
* Move `lift_results` function to `Func`
Also rename the lift/lower helpers to `with_{lift,lower}_context`
* Remove parameter from `with_lift_context`
Like `with_lower_context` this is fine to capture in the closure passed in.
* Simplify the dynamic lifting logic
Don't call `with_lift_context` in two locations, only call it once with a dynamic parameter.
* Refactor away the `Func::lift_results_sync` helper
* Use `with_lift_context` in `call_raw`
* Simplify a call to `Func::call_unchecked_raw`
* Ungate `with_lift_context` to fix non-cm-async build
* Fix compile (bad cherry-pick conflict resolution)
* Use `with_lower_context` in `call_raw`
Trying to unify the async/concurrent paths as much as possible.
* Move params out of `call_raw`
Let closures capture the params, no need to thread it through as an unnecessary argument.
* Clean up unsafety in `Func::call_raw`
* Accurately mark `call_raw` itself as `unsafe`, then document why callers should be safe. * Don't have one large `unsafe` block in `call_raw`, instead split it up with separate safety comments.
* Move a one-off type definition closer to its use
* Avoid intermediate allocations in dynamic calls
* Simplify a future-return site
* Deduplicate checking parameter count
* Simplify a future invocation with `?`
* Simplify a variable declaration
* Simplify some function signatures
* Remove outdated safety comment
* Refactor to not require `Params: 'static` on `call_async`
* Remove no-longer-necessary SAFETY comment
* Fix typos
* Add a fast-path with no `Box` for sync host functions
Speeds up host calls by ~20% and puts them back on parity with the beforehand numbers Wasmtime has.
* Synchronize signatures of async/concurrent dynamic calls
Use slices for both instead of vecs for one and slices for the other. Required some slight rejiggering. Apparently one can solve a closure problem with another closure, then one surely has no more closure problems.
* Fix non-cm-async build
---------
Signed-off-by: Joel Dice <[email protected]> Co-authored-by: Alex Crichton <[email protected]>
show more ...
|
|
Revision tags: v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0 |
|
| #
90ac295e |
| 19-May-2025 |
Alex Crichton <[email protected]> |
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 ...
|
| #
28e26fdf |
| 30-Apr-2025 |
Alex Crichton <[email protected]> |
Collapse resource tables to be per-instance, not per-resource (#10701)
This commit is an update to how Wasmtime represents and processes resource handles for components. The upstream specification c
Collapse resource tables to be per-instance, not per-resource (#10701)
This commit is an update to how Wasmtime represents and processes resource handles for components. The upstream specification changed in WebAssembly/component-model#427 and while it's been awhile since that change this is Wasmtime catching up to that change. It's expected that these paths are going to get stressed more with component model async and more kinds of handles so this additionally refactors things to leave sort of "holes" where async resources are going to go.
This notably will result in different behavior for guest programs. Previously if there were two resources imported into a guest they could have overlapping indices and now they're going to all have disjoint indices since they're all in the same index space. It's expected that this is will have a minimal, if any, impact on component guests as in theory they're all mostly treating handles as opaque indexes today anyway.
show more ...
|
|
Revision tags: v32.0.0, v31.0.0, v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0, v28.0.1, v28.0.0, v27.0.0, v26.0.1, v25.0.3, v24.0.2, v26.0.0, v21.0.2, v22.0.1, v23.0.3, v25.0.2, v24.0.1, v25.0.1, v25.0.0, v24.0.0, v23.0.2, v23.0.1, v23.0.0, v22.0.0 |
|
| #
1512a954 |
| 14-Jun-2024 |
Nick Fitzgerald <[email protected]> |
Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)
* Add `anyhow` stuff to our internal `wasmtime` crate prelude
We use it basically everywhere and it is annoying to have to import
Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)
* Add `anyhow` stuff to our internal `wasmtime` crate prelude
We use it basically everywhere and it is annoying to have to import.
I also did an audit of existing `use` statements and removed the now-redundant ones and replaced one-off imports with usage of the prelude, so that the prelude is available by default in more places.
* Fix `cargo doc`
show more ...
|
|
Revision tags: v21.0.1, v21.0.0 |
|
| #
0e9121da |
| 16-May-2024 |
FrankReh <[email protected]> |
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 ...
|
|
Revision tags: v20.0.2 |
|
| #
81a89169 |
| 04-May-2024 |
Alex Crichton <[email protected]> |
Add support for `#![no_std]` to the `wasmtime` crate (#8533)
* Always fall back to custom platform for Wasmtime
This commit updates Wasmtime's platform support to no longer require an opt-in `RUSTF
Add support for `#![no_std]` to the `wasmtime` crate (#8533)
* Always fall back to custom platform for Wasmtime
This commit updates Wasmtime's platform support to no longer require an opt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becoming officially supported this should provide a better onboarding experience where the fallback custom platform is used. This will cause linker errors if the symbols aren't implemented and searching/googling should lead back to our docs/repo (eventually, hopefully).
* Change Wasmtime's TLS state to a single pointer
This commit updates the management of TLS to rely on just a single pointer rather than a pair of a pointer and a `bool`. Additionally management of the TLS state is pushed into platform-specific modules to enable different means of managing it, namely the "custom" platform now has a C function required to implement TLS state for Wasmtime.
* Delay conversion to `Instant` in atomic intrinsics
The `Duration` type is available in `no_std` but the `Instant` type is not. The intention is to only support the `threads` proposal if `std` is active but to assist with this split push the `Duration` further into Wasmtime to avoid using a type that can't be mentioned in `no_std`.
* Gate more parts of Wasmtime on the `profiling` feature
Move `serde_json` to an optional dependency and gate the guest profiler entirely on the `profiling` feature.
* Refactor conversion to `anyhow::Error` in `wasmtime-environ`
Have a dedicated trait for consuming `self` in addition to a `Result`-friendly trait.
* Gate `gimli` in Wasmtime on `addr2line`
Cut down the dependency list if `addr2line` isn't enabled since then the dependency is not used. While here additionally lift the version requirement for `addr2line` up to the workspace level.
* Update `bindgen!` to have `no_std`-compatible output
Pull most types from Wasmtime's `__internal` module as the source of truth.
* Use an `Option` for `gc_store` instead of `OnceCell`
No need for synchronization here when mutability is already available in the necessary contexts.
* Enable embedder-defined host feature detection
* Add `#![no_std]` support to the `wasmtime` crate
This commit enables compiling the `runtime`, `gc`, and `component-model` features of the `wasmtime` crate on targets that do not have `std`. This tags the crate as `#![no_std]` and then updates everything internally to import from `core` or `alloc` and adapt for the various idioms. This ended up requiring some relatively extensive changes, but nothing too too bad in the grand scheme of things.
* Require `std` for the perfmap profiling agent
prtest:full
* Fix build on wasm
* Fix windows build
* Remove unused import
* Fix Windows/Unix build without `std` feature
* Fix some doc links
* Remove unused import
* Fix build of wasi-common in isolation
* Fix no_std build on macos
* Re-fix build
* Fix standalone build of wasmtime-cli-flags
* Resolve a merge conflict
* Review comments
* Remove unused import
show more ...
|
|
Revision tags: v20.0.1 |
|
| #
72004aad |
| 30-Apr-2024 |
Nick Fitzgerald <[email protected]> |
Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)
* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate
* Rewrite uses of `wasmtime
Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)
* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate
* Rewrite uses of `wasmtime_runtime` to `crate::runtime::vm`
* Remove dep on `wasmtime-runtime` from `wasmtime-cli`
* Move the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module
* Update labeler for merged crates
* Fix `publish verify`
prtest:full
show more ...
|