Changes in libcalls.rs

958860e8 - Fix overlap assertions in string transcoding (#12893)

Mon, 30 Mar 2026 23:37:54 +0000

Fix overlap assertions in string transcoding (#12893)Fixes an off-by-one assertion which is possible to happen when linearmemories are directly adjacent to each other. While an esotericsituation, it's technically possible as the added test shows.Closes #12678 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

da093747 - Relax panics in async/futures to traps/errors (#12688)

Mon, 02 Mar 2026 21:26:40 +0000

Relax panics in async/futures to traps/errors (#12688)* Relax panics in async/futures to traps/errorsThis commit is an admittance that I don't believe we're going to getto a point where we are confident enough in the fuzzing ofcomponent-model-async such that we could confidently say we'reexercising the vast majority of possible panics. Development ofcomponent-model-async has shown a steady trickle of panics over thecourse of the development of the feature, and this trend has beenpersistent over time as well.An attempt was made in #12119 to add a fuzzer dedicated to async eventsbut that didn't actually find anything in development and it has misseda number of panics present before and discovered after its introduction.Overall I do not know how to improve the fuzzer to the point that itwould find pretty much all of the existing async-related panics overtime.To help address this concern of the `concurrent.rs` implementation thiscommit goes through and replaces things like `unwrap()`, `assert!`,`panic!`, and `unreachable!` with an error-producing form. The benefitof this is that a bug in the implementation is less likely to result ina panic and instead just results in a non-spec-compliant trap. Thedownside of doing this though is that it can become unclear what errorsare "first class traps", or expected to be guest reachable, and whichare expected to be bugs in Wasmtime. To help address this I've performeda 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 systemis 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. Thisreduces the real-world impact of hitting these scenarios by downgrading aCVE-worthy `panic!` into a bug-worthy non-spec-compliant trap. Not allpanics are able to be transitioned to this as some are load bearing froma safety perspective or similar (or indicate something equally broken),but the vast majority of cases are suitable for "return a trap, lockdown 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 ofpanicking.* Fix CI build* Translate `WasmtimeBug` to panics in debug mode* Review comments* Refactor some stream methods for fewer panics List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

d2fbd2de - Update to wasm-tools 245 (#12571)

Thu, 12 Feb 2026 15:38:22 +0000

Update to wasm-tools 245 (#12571)* Intrinsics updates* Remove ds_store* Update to wasm-tools 245* Add vets* Fixup tests* Add missing feature for `indexmap`---------Co-authored-by: Sy Brand List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

3764e757 - Refactor borrow state tracking for async tasks (#12550)

Tue, 10 Feb 2026 03:15:51 +0000

Refactor borrow state tracking for async tasks (#12550)* Refactor borrow state tracking for async tasksThis commit is a somewhat deep refactoring of how the state of`borrow` is managed for both the host and the guest with respect toasync tasks. This additionally refactors how some async task managementis done for host-called functions.The fundamental problem being tackled here is #12510. In that issue itwas discovered that the way `CallContext`, the borrow tracking mechanismin Wasmtime, is managed is incompatible with async tasks. Specificallythe previous assumption of the scope being mutated for a borrow issomewhere on the call stack is no longer true. It's possible for anasync task to be suspended, for example, and then a sibling task drops aborrow which should update the scope of the suspended task. There were anumber of other small issues I noticed here and there which this PRadditionally has tests for, all of which failed before this change andpass afterwards.The manner in which borrow state is manipulated is a pretty old part ofthe component model implementation dating back to the originalimplementation of resources. I decided to forgo any possible quick fixand have attempted to more deeply refactor and integrate async tasksinto 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` 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` 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`. 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 originalissue. This then adds new tests to ensure that cleanup of variousconstructs happens appropriately, such as cancelling a host task shouldclean up its associated resources. Additionally synchronously calling anasync host task no longer leaks resources in a `Store` and shouldproperly clean up everything.There is still more work to do in this area (e.g. #12544) but that'sgoing to be deferred to a future PR at this point.Closes #12510prtest:full* Review comments/CI fixes List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

4d129904 - Check may-leave flags in trampolines, not Rust (#12427)

Tue, 03 Feb 2026 20:01:03 +0000

Check may-leave flags in trampolines, not Rust (#12427)This commit moves all may-leave flag handling into compiled trampolinesrather than doing this in Rust. This means it can't be forgotten on theRust side of things and will be slightly more efficient to boot. Thisthen additionally exempts some intrinsics from checking may-leave sinceWasmtime erroneously checked when it shouldn't have.Closes #12397Closes #12403 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

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

Fri, 23 Jan 2026 17:51:19 +0000

consistently create thread and task when entering component instance (#12379)* consistently create thread and task when entering component instancePreviously, we weren't creating a new thread or task in all cases when enteringa component instance, even when component model async features were enabled. Inparticular, entering an instance via a sync-to-sync, guest-to-guest adapter, via`Linker::instantiate[_async]`, or via `[Typed]Func::call` all skipped creating athread or task, creating panics and/or instance mismatches in certain cases.This commit addresses all those cases and also adds assertions to all CM asyncintrinsics to verify that the caller instance matches the most-recently-pushedtask. Note that we still skip pushing and popping threads and tasks if no CMasync features are enabled in the `Config`.In order to populate the `GuestTask::instance` field for tasks created as partof `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. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

b856261d - refactor recursive reentrance checks (#12349)

Wed, 14 Jan 2026 22:27:49 +0000

refactor recursive reentrance checks (#12349)* refactor recursive reentrance checksThis commit makes a few changes related to recursive reentrance checks, instancepoisoning, etc.:- Implements the more restrictive lift/lower rules described in https://github.com/WebAssembly/component-model/pull/589 such that a component instance may not lower a function lifted by one of its ancestors, nor vice-versa. Any such lower will result in a fused adapter which traps unconditionally, preventing guest-to-guest recursive reentrance without requiring data flow analysis. - Note that this required updating several WAST tests which were violating the new rule, including some in the `tests/component-model` Git submodule, which I've updated. - This is handled entirely in the `fact` module now; I've removed the `AlwaysTrap` case previously handled by `wasmtime-cranelift`.- Removes `FLAG_MAY_ENTER` from `InstanceFlags`. It is no longer needed for guest-to-guest calls due to the above, and for guest-to-host-to-guest calls we can rely on either `FLAG_NEEDS_POST_RETURN` for sync-lifted functions or the `GuestTask` call stack for async-lifted functions.- Adds a `StoreOpaque::trapped` field which is set when _any_ instance belonging to that store traps, at which point the entire store is considered poisoned, meaning no instance belonging to it may be entered. This prevents indeterminant concurrent task state left over from the trapping instance from leaking into other instances.Note that this does _not_ include code to push and pop `GuestTask` instances forguest-to-guest sync-to-sync calls, nor for host-to-guest calls using e.g. thesynchronous `Func::call` API, so certain intrinsics which expect a `GuestTask`to be present such as `backpressure.inc` will still fail in such cases. I'lladdress that in a later PR.Also note that I made a small change to `wasmtime-wit-bindgen`, adding a `Send`bound on the `T` type parameter for `store | async` functions. This allowed meto recursively call `{Typed}Func::call_concurrent` from inside a host function,and it doesn't have any downsides AFAICT.Fixes #12128* bless bindgen expansions* bless disas tests* address review feedback* sync `trap.h` with `trap_encoding.rs`...and add const assertions to `trap.rs` to help avoid future divergence. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

ff33e949 - Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)

Fri, 09 Jan 2026 19:23:56 +0000

Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)We are trying to move to `format_err!` instead. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

fae9e6af - add missing may-block checks for sync-to-sync guest-to-guest calls (#12282)

Thu, 08 Jan 2026 22:16:30 +0000

add missing may-block checks for sync-to-sync guest-to-guest calls (#12282)* add missing may-block checks for sync-to-sync guest-to-guest callsPreviously, we weren't updating or checking the may-block status of a taskacross sync-to-sync, guest-to-guest calls, meaning we were allowing blocking incases we shouldn't have.This fixes that by adding a new `task_may_block` field to `VMComponentContext`,plus code to update it every time we switch threads or do a sync-to-sync,guest-to-guest call. We use that field as the source of truth about whether ablocking operation is permitted.I've updated various tests to match, and Luke has an item on his to-do list toadd sad-path coverage for various cases to the upstream `component-model` testsuite.* address review feedback and fix component_instance_size_limit test* remove `TaskMayBlock` type per review feedback* bless disas tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

967f4601 - generate precise traps in component adapters (#12215)

Tue, 23 Dec 2025 21:00:39 +0000

generate precise traps in component adapters (#12215)* generate precise traps in component adaptersPreviously, we generated a generic `unreachable` instruction for each trap in afused adapter, plus some metadata to recover the specific kind of trap.However, that metadata was never hooked up to anything, so we only got a generic`unreachable` message at runtime.This commit removes the metadata tracking and instead simply calls a hostintrinsic, passing the trap code as a parameter. This is somewhate pessimalcompared with what we had before, but improves ergonomics and allows us to avoidforking as many tests from the component-model repo.If performance becomes an issue, we can easily add an option to skip the hostcall and only emit an `unreachable` instruction as before.Note that I've removed forked versions of three tests in favor of their upstreamequivalents.Fixes #11683* update `strings.rs` tests* bless disas tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

cb97ae85 - allow recursive Wasm invocation from concurrent host functions (#12152)

Thu, 11 Dec 2025 23:03:58 +0000

allow recursive Wasm invocation from concurrent host functions (#12152)* allow recursive Wasm invocation from concurrent host functionsThe 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 uniqueWhile discussing the above with Alex, we realized the use of a `HashMap` totrack per-instance states was both pessimal and unnecessary. Consequently, I'vefolded that state into `ComponentInstance::instance_handle_tables`, renaming itto `instance_states`. That involved a fair amount of code churn, but doesn'tchange behavior except as described in the second bullet point above.Thanks to Alex for the test case!Fixes #12098Co-authored-by: Alex Crichton Signed-off-by: Joel Dice * use new `RuntimeInstance` type instead of tuplesSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

7dc07b3b - Remove support for `backpressure.set` (#12130)

Tue, 09 Dec 2025 15:59:38 +0000

Remove support for `backpressure.set` (#12130)This canonical intrinsic which is part of component-model-async supportis supplanted by `backpressure.{inc,dec}`. This wasn't removed when theywere added to keep existing programs working, but that's no longernecessary. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

8992b99b - trap on blocking call in sync task before return (#12043)

Tue, 09 Dec 2025 15:41:57 +0000

trap on blocking call in sync task before return (#12043)* trap on blocking call in sync task before returnThis implements a spec change (PR pending) such that tasks created for calls tosynchronous exports may not call potentially-blocking imports or return `wait`or `poll` callback codes prior to returning a value. Specifically, thefollowing are prohibited in that scenario:- returning callback-code.{wait,poll}- sync calling an async import- sync calling subtask.cancel- sync calling {stream,future}.{read,write}- sync calling {stream,future}.cancel-{read,write}- calling waitable-set.{wait,poll}- calling thread.suspendThis breaks a number of tests, which will be addressed in follow-up commits:- The `{tcp,udp}-socket.bind` implementation in `wasmtime-wasi` is implemented using `Linker::func_wrap_concurrent` and thus assumed to be async, whereas the WIT interface says they're sync, leading to a type mismatch error at runtime. Alex and I have discussed this and have a general plan to address it.- A number of tests in the tests/component-model submodule that points to the spec repo are failing. Those will presumably be fixed as part of the upcoming spec PR (although some could be due to bugs in this implementation, in which case I'll fix them).- A number of tests in tests/misc_testsuite are failing. I'll address those in a follow-up commit.Signed-off-by: Joel Dice * call `check_may_leave` before `check_blocking``check_blocking` needs access to the current task, but that's not set forpost-return functions since those should not be calling _any_ imports at all, sofirst check for that.Signed-off-by: Joel Dice * fix `misc_testsuite` test regressionsThis amounts to adding `async` to any exported component functions that mightneed to block.Signed-off-by: Joel Dice * simplify code in `ConcurrentState::check_blocking`Signed-off-by: Joel Dice * make `thread.yield` a no-op in non-blocking contextsPer the proposed spec changes, `thread.yield` should return control to the guestimmediately without allowing any other thread to run. Similarly, when anasync-lifted export or callback returns `CALLBACK_CODE_YIELD`, we should callthe callback again immediately without allowing another thread to run.Signed-off-by: Joel Dice * fix build when `component-model-async` feature disabledSigned-off-by: Joel Dice * fix more test regressionsSigned-off-by: Joel Dice * fix more test regressionsNote that this temporarily updates the `tests/component-model` submodule to thebranch for https://github.com/WebAssembly/component-model/pull/577 until that PRis merged.Signed-off-by: Joel Dice * tweak `Trap::CannotBlockSyncTask` messageThis clarifies that such a task cannot block prior to returning.Signed-off-by: Joel Dice * fix cancel_host_future testSigned-off-by: Joel Dice * trap sync-lowered, guest->guest async calls in sync tasksI somehow forgot to address this earlier. Thanks to Luke for catching this.Note that this commit doesn't include test coverage, but Luke's forthecomingtests in the `component-model` repo will cover it, and we'll pull that in withthe next submodule update.Signed-off-by: Joel Dice * switch back to `main` branch of `component-model` repo...and skip or `should_fail` the tests that won't pass untilhttps://github.com/WebAssembly/component-model/pull/578 is merged.Signed-off-by: Joel Dice * add `trap-if-block-and-sync.wast`We'll remove this again in favor of the upstream version oncehttps://github.com/WebAssembly/component-model/pull/578 has been merged.Signed-off-by: Joel Dice * address review feedback- Assert that `StoreOpaque::suspend` is not called in a non-blocking context except in specific circumstances- Typecheck async-ness for dynamic host functions- Use type parameter instead of value parameter in `call_host[_dynamic]`Signed-off-by: Joel Dice * add explanation comments to `check_blocking` callsSigned-off-by: Joel Dice * fix fuzz test oracle for async functionsSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

e06fbf70 - Cooperative Multithreading (#11751)

Mon, 27 Oct 2025 21:39:35 +0000

Cooperative Multithreading (#11751)* Initial work* Almost compiling* Partially working* Cleanup* Fix merge* Cancellation and suspension refactoring* Remove printlns* Test with several threads* More testing* Cancellation* Fix cancellation for explicit suspends* Finish cancellation test* Store threads in the instance table* Deletion almost there* Tests all pass* Tighten up task deletion* Set thread state correctly* Store pairs of thread and task ids* Remove lift abi members* Cleanup unnecessary change* More cleanup* Cleanup* Revert cargo changes* Revert cargo changes* Comments* Comments on test* Update comments* Update comments* Add space that was removed in an earlier commit* Cleanup* Delete threads from the instance table* Revert cargo file* Remove dead code* Clippy changes* Clippy* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Review comments* Review feedback* Make thread IDs per-component-instance* Fix config* Tighten up completion* Clippy* Trigger full PR test* Move funcref table reading* Remove unused import* Formatting* Rename RemoveOnDrop* Review feedback* Review feedback* Move start thread closure* Review feedback* Review feedback* Correct feature for import* Review feedback* Disable failing tests* Enable fixed tests* Review feedback* Readd tests* Ignore task deletion test with Miri List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

778771d2 - Update nightly rust used in CI (#11856)

Wed, 15 Oct 2025 15:47:02 +0000

Update nightly rust used in CI (#11856)* Update nightly rust used in CIA few more warnings are cropping up so squash them.* Frob the `unreachable_code` lintLooks like nightly rust has gotten much more aggressive about linting onunreachable code.prtest:full* Allow some more warnings... List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

7e39c25e - move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)

Mon, 06 Oct 2025 19:53:10 +0000

move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)* move `ConcurrentState` from `ComponentInstance` to `Store`This has a few benefits:- No need to specify an instance when creating or piping from a stream or future.- No need to track the instance in an `Accessor`.- You may now execute tasks for multiple instances in a single event loop.The main drawback is that, if one of several instances within a single storetraps, it effectively means all instances have trapped, and the store can't beused to create new instances. The way to avoid that is to use separate storesfor instances which must be isolated from others.As a result of this change, a lot of code had to move from e.g. `impl Instance`to e.g. `impl StoreOpaque`, so the diff is pretty huge, but the changesthemselves are almost entirely non-functional.Fixes #11226Signed-off-by: Joel Dice * fix non-component-model-async buildSigned-off-by: Joel Dice * fix outdated doc commentSigned-off-by: Joel Dice * address review feedback- restore `ComponentStoreData` encapsulation- avoid conditional code duplication in `LiftContext::new`Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

6751ea79 - disallow exiting a component instance during a post-return call (#11688)

Thu, 11 Sep 2025 23:26:34 +0000

disallow exiting a component instance during a post-return call (#11688)* disallow exiting a component instance during a post-return callThis is a relatively recent change to the spec.In order to check the `may_leave` flag in all the relevant intrinsics, I had toplumb the caller `RuntimeComponentInstanceIndex` through a bunch of trampolinesthat didn't previously need it, hence the large diff.Note that I've added a slightly tweaked version of `trap-in-post-return.wast`and left the upstream version disabled in `test-util/src/wast.rs` due to #11683.Fixes #11676.Signed-off-by: Joel Dice * fix test regressionsSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

58c5085a - Implement `backpressure.{inc,dec}` (#11661)

Wed, 10 Sep 2025 23:12:29 +0000

Implement `backpressure.{inc,dec}` (#11661)Added to the async specification in WebAssembly/component-model#560these are minor adaptations to the preexisting `backpressure.set`intrinsic and are intended to replace it. The `backpressure.set`intrinsic will remain until tooling propagates to understand`backpressure.{inc,dec}`. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

88b630db - Update to wasm-tools 239 (#11660)

Wed, 10 Sep 2025 18:26:52 +0000

Update to wasm-tools 239 (#11660)Changes include:* `async` option on some CM intrinsics renamed to `cancellable`* New `backpressure.{inc,dec}` intrinsics* New component-model-threading-related intrinsicsNew features aren't yet implemented, they're left for future PRs. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs

066ff8be - support non-async `{stream,future}.cancel-{read,write}` (#11625)

Mon, 08 Sep 2025 19:54:35 +0000

support non-async `{stream,future}.cancel-{read,write}` (#11625)* support non-async `{stream,future}.cancel-{read,write}`During my earlier stream API refactoring, I had forgotten to support or testsynchronous cancellation; this commit does both. In the process, I realized thefuture API ought to be updated to support blocking cancellation just like thestream API, so I made that change as well.This also adds `{Source,Destination}::reborrow` functions, allowing instances ofthose types to be reborrowed, such that they may be passed as parameters butalso used again.Note that I had to move some functions from `impl ConcurrentState` to `implInstance` in order to access the store and suspend the current fiber whensynchronously cancelling.Signed-off-by: Joel Dice * reduce code duplicationSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/libcalls.rs