Changes in runtime.rs

9bc302ad - Reduce type complexity of `InstanceAllocator` async functions (#12887)

Mon, 30 Mar 2026 15:02:12 +0000

Reduce type complexity of `InstanceAllocator` async functions (#12887)This is a follow-on to #12849 to try to simplify some of the resultingsignatures a bit. Notably the `Result<..., OutOfMemory>` is now packagedup directly into the output future, so the functions still retain a sortof "async trait" feel even though they're still incompatible with`#[async_trait]` (and can't be defined with that anyway). List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.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.rs

c12e1698 - Move `StringPool` to `wasmtime-environ` (#12562)

Wed, 11 Feb 2026 16:43:10 +0000

Move `StringPool` to `wasmtime-environ` (#12562)* Move `StringPool` to `wasmtime-environ`* Remove old location's `mod` declaration* always implement TryClone for hashbrown::DefaultHashBuilder List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

0c673b70 - Add a reusable `StringPool` for interning strings (#12536)

Fri, 06 Feb 2026 18:34:57 +0000

Add a reusable `StringPool` for interning strings (#12536)* Add a reusable `StringPool` for interning stringsAnd make sure it handles allocation failure.* fix string pool tests* Address review feedback* One more piece of review feedback that got missed List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

1d738975 - Use `core::convert::Infallible` instead of our own `Uninhabited` type (#12115)

Wed, 03 Dec 2025 21:32:48 +0000

Use `core::convert::Infallible` instead of our own `Uninhabited` type (#12115)* Use `core::convert::Infallible` instead of our own `Uninhabited` typeI didn't realize that the standard library already had an uninhabited typeavailable for us to reuse.* Actually remove the uninhabited module and its re-exports List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

02155232 - Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)

Wed, 15 Oct 2025 00:03:52 +0000

Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.This PR implements ideas from the [recent RFC] to serve as the basisfor Wasm (guest) debugging: it adds a stackslot to each functiontranslated from Wasm, stores to replicate Wasm VM state in thestackslot as the program runs, and metadata to describe the format ofthat state and allow reading it out at runtime.As an initial user of this state, this PR adds a basic "stack view"API that, from host code that has been called from Wasm, can examineWasm frames currently on the stack and read out all of their localsand stack slots.Note in particular that this PR does not include breakpoints,watchpoints, stepped execution, or any sort of user interface for anyof this; it is only a foundation.This PR still has a few unsatisfying bits that I intend to address:- The "stack view" performs some O(n) work when the view is initially taken, computing some internal data per frame. This is forced by the current design of `Backtrace`, which takes a closure and walks that closure over stack frames eagerly (rather than work as an iterator). It's got some impressive iterator-chain stuff going on internally, so refactoring it to the latter approach might not be *too* bad, but I haven't tackled it yet. A O(1) stack view, that is, one that does work only for frames as the host API is used to walk up the stack, is desirable because some use-cases may want to quickly examine e.g. only the deepest frame (say, running with a breakpoint condition that needs to read a particular local's value after each step).- It includes a new `Config::compiler_force_inlining()` option that is used only for testing that we get the correct frames after inlining. I couldn't get the existing flags to work on a Wasmtime config level and suspect there may be an existing bug there; I will try to split out a fix for it.This PR renames the existing `debug` option to `native_debug`, todistinguish it from the new approach.[recent RFC]: https://github.com/bytecodealliance/rfcs/pull/44* Update to new APIs on Cranelift side.* Test update.* Adjust objdump printing of InstPos on frame progpoints; and adjust progpoint collapsing.* Convert to iterator form.* Fix path in native-debug tests (debug -> native_debug rename).* Enforce that `debug_instrumentation` can only be enabled when feature is enabled.* Add missing assert.* Use builtin knob for forcing intra-module inlining instead.* Review feedback:- Make StackView own the current frame rather than handing it out. This prevents the current frame (`FrameView`) from walking away and hiding somewhere it shouldn't, to be used unsoundly later.- Assert no-GC during stack walk.* Merge debug-instrumentation hooks on FuncEnvironment into before/after hooks.* Review feedback: avoid downcasting funcs twice.* Add debug feature to `wasmtime` crate's defaults.* Review feedback: u32s for local and stack indices in debug host API.* Use *const u8 as stack pointers and `with_exposed_provenance` in debug API.* Remove some `srcloc` plumbing in Wasm translator.* Rename native-debug back to debug, and make the new thing "guest debugging".* rustfmt in debugging test.* fix disas test after guest-debug CLI option rename.* Review feedback: no separate debug-instrumentation hooks on FuncEnvironment.* Review feedback: update doc comment on `Config::guest_debug`.* Review feedback: rename `generate_debuginfo` to `debug_native` in tunables.* Review feedback: miscellaneous comments.* Review comment: fix wording in safety conditions.* revert wasi-common submodule update* Properly root values in debug frame slots.Fixes #11841.* Fix non-`debug`-feature build.* Review feedback: naming.* Ignore tests that compile modules in miri. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

becdee57 - Add PoolingAllocatorMetrics (#11490)

Fri, 22 Aug 2025 16:04:42 +0000

Add PoolingAllocatorMetrics (#11490)This exposes some basic runtime metrics derived from the internal stateof a `PoolingInstanceAllocator`.Two new atomics were added to PoolingInstanceAllocator: `live_memories`and `live_tables`. While these counts could be derived from existingstate it would require acquiring mutexes on some inner state. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

2d25f862 - WebAssembly exception-handling support. (#11326)

Thu, 21 Aug 2025 02:55:44 +0000

WebAssembly exception-handling support. (#11326)* WebAssembly exception-handling support.This PR introduces support for the [Wasm exception-handling proposal],which introduces a conventional try/catch mechanism to WebAssembly. ThePR supports modules that use `try_table` to register handlers for alexical scope; and provides `throw` and `throw_ref` that allocate (inthe first case) and throw exception objects.This PR builds on top of the work in #10510 for Cranelift-levelexception support, #10919 for an unwinder, and #11230 for exceptionobjects built on top of GC, in addition a bunch of smaller fix andenabling PRs around those.[Wasm exception-handling proposal]: https://github.com/WebAssembly/exception-handling/prtest:full* Permit UnwindToWasm to have unused fields in Pulley builds (for now).* Resolve miri-caught reborrowing issue.* Ignore exceptions tests in miri for now (Pulley not supported).* Use wasmtime_test on exceptions tests.* Get tests passing on pulley platforms* Add a check to `supports_host` for the generated test and assert failure also when that is false.* Remove `pulley_unsupported` test as it falls out of `#[wasmtime_test]`* Remove `exceptions_store` helper as it falls out of `#[wasmtime_test]`* Remove miri annotations as they fall out of `#[wasmtime_test]`* Remove dead import* Skip some unsupported tests entirely in `#[wasmtime_test]`If the selected compiler doesn't support the host at all then there's noneed to run it. Actually running it could misinterpret `CraneliftNative`as "run with pulley" otherwise, so avoid such false negatives.* Cranelift: dynamic contexts: account for outgoing-args area.---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

8d4e9234 - Resolve `unsafe_op_in_unsafe_fn` in `wasmtime` crate (#11432)

Thu, 14 Aug 2025 14:22:41 +0000

Resolve `unsafe_op_in_unsafe_fn` in `wasmtime` crate (#11432)Just a few unsafe blocks remainCloses #11180 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

0f457fad - Raise `unsafe_op_in_unsafe_fn` further in Wasmtime (#11322)

Fri, 25 Jul 2025 18:22:03 +0000

Raise `unsafe_op_in_unsafe_fn` further in Wasmtime (#11322)* Raise `unsafe_op_in_unsafe_fn` further in WasmtimeNow it's at `wasmtime::runtime`, not just `wasmtime::runtime::vm`.* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

b63c25ae - fix(no_std)!: respect `std` feature when target is windows/unix (#11152)

Thu, 03 Jul 2025 22:07:42 +0000

fix(no_std)!: respect `std` feature when target is windows/unix (#11152)* fix(no_std)!: respect `std` feature when target is windows/unixBREAKING CHANGE: the fix disables standard features for dependents that use wasmtime with `default-features = false`.* fix cargo check workflow* Don't require `std` feature for invalid faultsFill out the `compile_error!` to avoid failing a build.* addressing review comments* add `std` to `stack-switching` feature* remove `rustix/mm` from `std` feature dependencies* add `std` feature flag to `jit-icache-coherence`- The `std` feature gates the use of standard library for icache coherence in Windows; otherwise, defaults to the `libc` implementation.- The `std` feature of Wasmtime now depends on the `wasmtime-jit-icache-coherence/std`* Only include jit-icache-coherence on `std` buildsprtest:full* Fix some idiom issues* More idiom issues* Require `std` for loading native code---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

421136d0 - generalize async fiber abstraction (#11114)

Thu, 26 Jun 2025 21:52:21 +0000

generalize async fiber abstraction (#11114)* generalize async fiber abstractionAs part of the work implementing the new Component Model async ABI in the`wasip3-prototyping` repo, I've generalized the `FiberFuture` abstraction in`wasmtime::runtime::store::async_` to support fibers which can either retainexclusive access to the store across suspend points or release it. The latterallows the store to be used by the `component-model-async` event loop and/orother fibers to run before the original fiber resumes, which is the key toallowing multiple fibers to run concurrently, passing control of the store backand forth.In the case of Pulley, the above generalization means we also need to give eachfiber its own `Interpreter` so that multiple concurrent fibers don't clobbereach other's state.Concretely, this moves a lot of the code out of `async_.rs` and into a new`fiber.rs` submodule which will be shared with the `component-model-async`implementation.This also pulls in a new `StoreToken` utility which has been useful in`wasip3-prototyping` to safely convert from a `&mut dyn VMStore` to a`StoreContextMut<'a, T>` when we previously witnessed a conversion in the otherdirection.Note that I've added a `'static` bound to the `VMStore` trait, which simplifiesuse of `&mut dyn VMStore`, avoiding thorny lifetime issues.Signed-off-by: Joel Dice * address review feedbackSigned-off-by: Joel Dice * fix miri-flagged stacked borrow violationAs part of my earlier effort to unify the fiber abstractions in the `wasmtime`crate, I changed a `*mut StoreFiber` field to a `&mut StoreFiber`, not realizingthat it resulted in a mutable alias at runtime and thus undefined behavior.Miri caught it, fortunately.Signed-off-by: Joel Dice * remove unneeded `Send` boundsSigned-off-by: Joel Dice * address more review feedbackMain changes:- Make `resume_fiber[_raw]` take a `&mut StoreOpaque` parameter to make its unsafe internals easier to reason about, safety-wise.- Panic if `StoreFiber::drop` is called on an in-progress fiber without having called `StoreFiber::dispose` to gracefully end it first.- (Re)introduce `FiberFuture`, which closes over a `&mut StoreOpaque` and uses it to call `StoreFiber::dispose` on drop.This will require a few more changes to make it usable by `concurrent.rs`, butI'll save those changes for a later PR.Signed-off-by: Joel Dice * address more review feedbackSigned-off-by: Joel Dice * update `impl Send For StoreFiber` commentSigned-off-by: Joel Dice * Remove currently-extraneous `Result<()>` from fibersMay be needed for concurrent bits, but for now not necessary.* Use safe pointers instead of raw pointersIt's predicted Miri won't like this, but for now in-repo it's ok with it.* Fold more responsibility into `resume_fiber_raw`Remove the need for the function entirely and replace it with`resume_fiber`.* Remove channels from async fibersCan use stack-based closures/results to transmit the result instead ofneeding a channel.* Fold `on_fiber_raw` directly into `on_fiber`The `on_fiber` function is small enough it should be possible to do so.* Don't use `Option` in `FiberFuture`Leave the fiber non-optional at-rest so it's always available for thedestructor.* Fold `suspend` functions togetherSmall shims, not otherwise public at this time, so remove a layer ofindirection.* Move stack limit management to `FiberResumeState`Helps remove some raw pointers that are held for a long time within`AsyncCx`* add some doc comments to `fiber.rs`Signed-off-by: Joel Dice * update `fiber.rs` and friends to match CM async requirementsThis adds a `resolve_or_release` function, which `Instance::resume_fiber` willuse when current `concurrent.rs` stub is replaced by a real implementation.Signed-off-by: Joel Dice * fix non-component-model-async build warningsSigned-off-by: Joel Dice * make `resume_fiber` private in `fiber.rs`Signed-off-by: Joel Dice * Shrink `PollContext` stateMove management of the async guard range elsewhere to the normalsave/restore area.* Refactor `AsyncCx`, reduce `unsafe`* Remove the `AsyncCx` type from Wasmtime as it's inherently `unsafe` to use, instead bundle operations directly on a `Store*` reference.* Don't retain pointers-to-pointers within the roughly-equivalent `BlockingContext` created in this PR. Instead when a blocking context is created "take" the metadata from the store to assert exclusive ownership of the pointers.* Refactor how `&mut Context<'_>` is passed around, namely thread it through fiber parameters to model resumption as registering a new context to poll with.* Remove `PollContext` in favor of directly storing a pointer as it's now mostly an empty structure.* Minor refactorings to make things more future-refactorable and/or clear in a few places.* Refactor management of the "current suspend" and "current future context" pointers. These are now null'd out on resumption and asserted null on suspension.* Remove the need for a generic `Reset` structure in the fiber bits as it's a pretty dangerous structure to have in general.The end result of this refactoring is that all usage of `block_on` isnow safe and additionally many of the internals of the implementationare safer than they were before* Adjust some lint attributes* Make manipulation of `AsyncState` safeNo need for raw pointers with recent refactorings.* Fix dead code warning* More dead code warnings* Cut down on raw pointers in fiber.rs* Move executor save/restore to normal fiber state save/restore* Bikeshed a method name* update comment in make_fiberSigned-off-by: Joel Dice * fix machports buildSigned-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.rs

ebd9824f - Start work towards always-warnings in wasmtime (#10131)

Tue, 28 Jan 2025 15:23:14 +0000

Start work towards always-warnings in wasmtime (#10131)* Start work towards always-warnings in `wasmtime`This commit is an attempt to make progress after #10108. The goal ofthis commit is to create a list of features to burn down over time andto have `dead_code` and `unused_imports` lints on-by-default inWasmtime. The `feature = "default"` gate on this `allow` directive wasreplaced with individual features. The hope is that as individualfeatures are removed from this list we can fix the resulting warningsand the commit such a ratchet.* Burn down some features from allowing dead codeRemove the features from the crate and test compiling with all otherfeatures to ensure that no warnings are issued.* Run full tests in CIprtest:full* Fix warning condition* Fix #[cfg] to fix warnings on iOSSwitch `target_os = "macos"` to `target_vendor = "apple"` to alignrequirements. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

4c6739f1 - Upstream wasm-wave instances in wasmtime (#8872)

Mon, 18 Nov 2024 20:12:13 +0000

Upstream wasm-wave instances in wasmtime (#8872)* wasmtime: add wasm-wave instances behind an off-by-default wave feature* cargo vet: trust the usuals, audit beef, exempt logos family* correct unrelated comment* wasmtime::component::wasm_wave re-exports the crate* convenience functions: component::Val::{to_wave, from_wave}.* fix componentfunc params List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

0bce0968 - Warn against `clippy::cast_possible_truncation` in Wasmtime (#9209)

Fri, 06 Sep 2024 22:25:50 +0000

Warn against `clippy::cast_possible_truncation` in Wasmtime (#9209)* Warn against `clippy::cast_possible_truncation` in WasmtimeThis commit explicitly enables the `clippy::cast_possible_truncation`lint in Clippy for just the `wasmtime::runtime` module. This does notenable it for the entire workspace since it's a very noisy lint and ingeneral has a low signal value. For the domain that `wasmtime::runtime`is working in, however, this is a much more useful lint. We in generalwant to be very careful about casting between `usize`, `u32`, and `u64`and the purpose of this module-targeted lint is to help with just that.I was inspired to do this after reading over #9206 where especially whenrefactoring code and changing types I think it would be useful to havelocations flagged as "truncation may happen here" which previouslyweren't truncating.The failure mode for this lint is that panics might be introduced wheretruncation is explicitly intended. Most of the time though this isn'tactually desired so the more practical consequence of this lint is toprobably slow down wasmtime ever so slightly and bloat it ever soslightly by having a few more checks in a few places. This is likelybest addressed in a more comprehensive manner, however, rather thanspecifically for just this one case. This problem isn't unique to justcasts, but to many other forms of `.unwrap()` for example.* Fix some casts in tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

3090ded8 - Add a compile-time feature for call hooks (#8795)

Thu, 13 Jun 2024 19:53:01 +0000

Add a compile-time feature for call hooks (#8795)* Add a compile-time feature for call hooksThis commit moves the `Store::call_hook` API behind a Cargo featurenamed `call-hook`. This helps speed up the path from wasm into the hostby avoiding branches at the start and the end of the execution. In athread on [Zulip] this is locally leading to significant performancegains in this particular microbenchmark so having an option to disableit at the crate layer seems like a reasonable way to thread this needlefor now. This definitely has a downside in that it requires a cratefeature at all, but I'm not sure of a better solution as LLVM can'tdynamically detect that `Store::call_hook` is never invoked andtherefore the branch can be optimized away.[Zulip]: https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/Performance.20regression.20since.20rust.201.2E65/near/444505571* Fix a feature build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

e1f8b9b7 - Wasmtime(pooling allocator): Batch decommits (#8590)

Tue, 14 May 2024 00:23:17 +0000

Wasmtime(pooling allocator): Batch decommits (#8590)This introduces a `DecommitQueue` for batching decommits together in the poolingallocator:* Deallocating a memory/table/stack enqueues their associated regions of memory for decommit; it no longer immediately returns the associated slot to the pool's free list. If the queue's length has reached the configured batch size, then we flush the queue by running all the decommits, and finally returning the memory/table/stack slots to their respective pools and free lists.* Additionally, if allocating a new memory/table/stack fails because the free list is empty (aka we've reached the max concurrently-allocated limit for this entity) then we fall back to a slow path before propagating the error. This slow path flushes the decommit queue and then retries allocation, hoping that the queue flush reclaimed slots and made them available for this fallback allocation attempt. This involved defining a new `PoolConcurrencyLimitError` to match on, which is also exposed in the public embedder API.It is also worth noting that we *always* use this new decommit queue now. Tokeep the existing behavior, where e.g. a memory's decommits happen immediatelyon deallocation, you can use a batch size of one. This effectively disablesqueueing, forcing all decommits to be flushed immediately.The default decommit batch size is one.This commit, with batch size of one, consistently gives me an increase on`wasmtime serve`'s requests-per-second versus its parent commit, as measured by`benches/wasmtime-serve-rps.sh`. I get ~39K RPS on this commit compared to ~35KRPS on the parent commit. This is quite puzzling to me. I was expecting nochange, and hoping there wouldn't be a regression. I was not expecting a speedup. I cannot explain this result at this time.prtest:fullCo-authored-by: Jamey Sharp List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

81a89169 - Add support for `#![no_std]` to the `wasmtime` crate (#8533)

Sat, 04 May 2024 22:02:26 +0000

Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime's platform support to no longer require anopt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becomingofficially supported this should provide a better onboarding experiencewhere the fallback custom platform is used. This will cause linkererrors if the symbols aren't implemented and searching/googling shouldlead back to our docs/repo (eventually, hopefully).* Change Wasmtime's TLS state to a single pointerThis commit updates the management of TLS to rely on just a singlepointer rather than a pair of a pointer and a `bool`. Additionallymanagement of the TLS state is pushed into platform-specific modules toenable different means of managing it, namely the "custom" platform nowhas a C function required to implement TLS state for Wasmtime.* Delay conversion to `Instant` in atomic intrinsicsThe `Duration` type is available in `no_std` but the `Instant` type isnot. The intention is to only support the `threads` proposal if `std` isactive but to assist with this split push the `Duration` further intoWasmtime to avoid using a type that can't be mentioned in `no_std`.* Gate more parts of Wasmtime on the `profiling` featureMove `serde_json` to an optional dependency and gate the guest profilerentirely 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 thenthe dependency is not used. While here additionally lift the versionrequirement for `addr2line` up to the workspace level.* Update `bindgen!` to have `no_std`-compatible outputPull most types from Wasmtime's `__internal` module as the source oftruth.* Use an `Option` for `gc_store` instead of `OnceCell`No need for synchronization here when mutability is already available inthe necessary contexts.* Enable embedder-defined host feature detection* Add `#![no_std]` support to the `wasmtime` crateThis commit enables compiling the `runtime`, `gc`, and `component-model`features of the `wasmtime` crate on targets that do not have `std`. Thistags the crate as `#![no_std]` and then updates everything internally toimport from `core` or `alloc` and adapt for the various idioms. Thisended up requiring some relatively extensive changes, but nothing tootoo bad in the grand scheme of things.* Require `std` for the perfmap profiling agentprtest: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 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

964f8986 - Use rustdoc's `doc_auto_cfg` feature instead of `doc_cfg` (#8532)

Fri, 03 May 2024 16:01:12 +0000

Use rustdoc's `doc_auto_cfg` feature instead of `doc_cfg` (#8532)This commit removes all our `#[cfg_attr(..., doc(cfg(...)))]`annotations throughout Wasmtime and `wasmtime-wasi`. These are allreplaced with `feature(doc_auto_cfg)` which automatically infers theattribute to show rather than requiring us to duplicate it.Spot-checking the docs this looks just-as-readable while being mucheasier to maintain over time. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs

72004aad - Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)

Tue, 30 Apr 2024 18:52:45 +0000

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 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime.rs