Changes in dead-code_async.rs

96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

Wed, 07 Jan 2026 17:08:11 +0000

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`Instead of `anyhow::Error`.This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`module, updates the prelude to include these new error-handling types, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse the new error types instead of `anyhow`.Part of https://github.com/bytecodealliance/wasmtime/issues/12069* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense* cargo fmt* Move `crate::error::Thing` to `crate::Thing` where it makes sense List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

1155d6df - Redesign function configuration in `bindgen!` (#11328)

Mon, 28 Jul 2025 18:31:06 +0000

Redesign function configuration in `bindgen!` (#11328)* Redesign function configuration in `bindgen!`This commit is a redesign of how function-level configuration works inWasmtime's `bindgen!` macro. The main goal of this redesign is tobetter support WASIp3 and component model async functions. Prior to thisredesign there was a mish mash of mechanisms to configure behavior ofimports/exports:* The `async` configuration could turn everything async, nothing async, only some imports async, or everything except some imports async.* The `concurrent_{imports,exports}` keys were required to explicitly opt-in to component model async signatures and applied to all imports/exports.* The `trappable_imports` configuration would indicate a list of imports allowed to trap and it had special configuration for everything, nothing, and only a certain list.* The `tracing` and `verbose_tracing` keys could be applied to either nothing or all functions.Overall the previous state of configuration in `bindgen!` was clearly ahodgepodge of systems that organically grew over time. In my personalopinion it was in dire need of a refresh to take into account howcomponent-model-async ended up being implemented as well asconsolidating the one-off systems amongst all of these configurationkeys. A major motivation of this redesign, for example, was to inheritbehavior from WIT files by default. An `async` function in WIT shouldnot require `concurrent_*` keys to be configured, but rather it shouldgenerate correct bindings by default.In this commit, all of the above keys were removed. All keys have beenreplaced with `imports` and `exports` configuration keys. Each behavesthe same way and looks like so: bindgen!({ // ... imports: { // enable tracing for just this function "my:local/interface/func": tracing, // enable verbose tracing for just this function "my:local/interface/other-func": tracing | verbose_tracing, // this is blocking in WIT, but generate async bindings for // it "my:local/interface/[method]io.block": async, // like above, but use "concurrent" bindings which have // access to the store. "my:local/interface/[method]io.block-again": async | store, // everything else is, by default, trappable default: trappable, }, });Effectively all the function-level configuration items are now bitflags.These bitflags are by default inherited from the WIT files itself (e.g.`async` functions are `async | store` by default). Further configurationis then layered on top at the desires of the embedder. Supported keys are:* `async` - this means that a Rust-level `async` function should be generated. This is either `CallStyle::Async` or `CallStyle::Concurrent` as it was prior, depending on ...* `store` - this means that the generated function will have access to the store on the host. This is only implemented right now for `async | store` functions which map to `CallStyle::Concurrent`. In the future I'd like to support just-`store` functions which means that you could define a synchronous function with access to the store in addition to an asynchronous function.* `trappable` - this means that the function returns a `wasmtime::Result`. If `trappable_errors` is applicable then it means just a `Result` is returned (like before)* `tracing` - this enables `tracing!` integration for this function.* `verbose_tracing` - this logs all argument values for this function (including lists).* `ignore_wit` - this ignores the WIT-level defaults of the function (e.g. ignoring WIT `async`).The way this then works is all modeled is that for any WIT functionbeing generated there are a set of flags associated with that function.To calculate the flags the algorithm looks like:1. Find the first matching rule in the `imports` or `exports` map depending on if the function is imported or exported. If there is no matching rule then use the `default` rule if present. This is the initial set of flags for the function (or empty if nothing was found).2. If `ignore_wit` is present, return the flags from step 1. Otherwise add in `async | store` if the function is `async` in WIT.The resulting set of flags are then used to control how everything isgenerated. For example the same split traits of today are stillgenerated and it's controlled based on the flags. Note though that theprevious `HostConcurrent` trait was renamed to `HostWithStore` to makespace for synchronous functions in this trait in the future too.The end result of all these changes is that configuring imports/exportsnow uses the exact same selection system as the `with` replacement map,meaning there's only one system of selecting functions instead of 3.WIT-level `async` is now respected by default meaning that bindings workby default without further need to configure anything (unless morefunctionality is desired).One final minor change made here as well is that auto-generated`instantiate` methods are now always synchronous and an`instantiate_async` method is unconditionally generated for async mode.This means that bindings always generate both functions and it's up tothe embedder to choose the appropriate one.Closes #11246Closes #11247* Update expanded test expectationsprtest:full* Fix the min platform embedding example* Fix doc tests* Always generate `*WithStore` traitsThis helps when using the `with` mapping since that can always assumethat `HostWithStore` is available in the generated bindings, avoidingthe need to duplicate configuration options.* Update test expectations* Review comments List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

7c790607 - Merge wasip3-prototyping bindgen changes to main (#10844)

Tue, 27 May 2025 22:22:33 +0000

Merge wasip3-prototyping bindgen changes to main (#10844)* Merge wasip3-prototyping bindgen changes to mainThis commit wholesale copies the `wasmtime-wit-bindgen` changes from thewasip3-prototyping repository to the Wasmtime repository here. This isdone to make the future merge with `wasip3-prototyping` smallercomplexity-wise.This is intended to be a no-functional-change for non-"concurrent"imports, or those for component model async. That means that it'sintended that no current embedding is affected by these changes.Internally though there has been restructuring.Namely internally the generation of an interface trait, a resourcetrait, and a world trait are all unified in a single method now. In thefuture with component model async these traits are being split intoasync/sync versions and so it was much nicer to do this in one locationrather than across three different locations.This required some minor renamings in the generated code and movingaround some impls, but otherwise the generated code should mostly be thesame as before (see golden output diff in the subsequent commit of thisPR)* Update test expectations List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

f6775a33 - Replace `GetHost` with a function pointer, add `HasData` (#10770)

Tue, 13 May 2025 05:47:01 +0000

Replace `GetHost` with a function pointer, add `HasData` (#10770)* Replace `GetHost` with a function pointer, add `HasData`This commit is a refactoring to the fundamentals of the `bindgen!` macroand the functions that it generates. Prior to this change thefundamental entrypoint generated by `bindgen!` was a function`add_to_linker_get_host` which takes a value of type `G: GetHost`. This`GetHost` implementation is effectively an alias for a closure whosereturn value is able to close over the parameter given lfietime-wise.The `GetHost` abstraction was added to Wasmtime originally to enableusing any type that implements `Host` traits, not just `&mut U` as wasoriginally supported. The definition of `GetHost` was _just_ right toenable a type such as `MyThing<&mut T>` to implement `Host` and aclosure could be provided that could return it. At the time that`GetHost` was added it was known to be problematic from anunderstandability point of view, namely:* It has a non-obvious definition.* It's pretty advanced Rust voodoo to understand what it's actually doing* Using `GetHost` required lots of `for<'a> ...` in places which is unfamiliar syntax for many.* `GetHost` values couldn't be type-erased (e.g. put in a trait object) as we couldn't figure out the lifetime syntax to do so.Despite these issues it was the only known solution at hand so we landedit and kept the previous `add_to_linker` style (`&mut T -> &mut U`) as aconvenience. While this has worked reasonable well (most folks just tryto not look at `GetHost`) it has reached a breaking point in the WASIp3work.In the WASIp3 work it's effectively now going to be required that the`G: GetHost` value is packaged up and actually stored inside ofaccessors provided to host functions. This means that `GetHost` valuesnow need to not only be taken in `add_to_linker` but additionallyprovided to the rest of the system through an "accessor". This was madepossible in #10746 by moving the `GetHost` type into Wasmtime itself (asopposed to generated code where it lived prior).While this worked with WASIp3 and it was possible to plumb `G: GetHost`safely around, this ended up surfacing more issues. Namely all"concurrent" host functions started getting significantly morecomplicated `where` clauses and type signatures. At the end of the day Ifelt that we had reached the end of the road to `GetHost` and wanted tosearch for alternatives, hence this change.The fundamental purpose of `GetHost` was to be able to express, in ageneric fashion:* Give me a closure that takes `&mut T` and returns `D`.* The `D` type can close over the lifetime in `&mut T`.* The `D` type must implement `bindgen!`-generated traits.A realization I had was that we could model this with a genericassociated type in Rust. Rust support for generic associated types isrelatively new and not something I've used much before, but it ended upbeing a perfect model for this. The definition of the new `HasData`trait is deceptively simple: trait HasData { type Data<'a>; }What this enables us to do though is to generate `add_to_linker`functions that look like this: fn add_to_linker( linker: &mut Linker, getter: fn(&mut T) -> D::Data<'_>, ) -> Result<()> where D: HasData, for<'a> D::Data<'a>: Host;This definition here models `G: GetHost` as a literal function pointer,and the ability to close over the `&mut T` lifetime with type (not just`&mut U`) is expressed through the type constructor `type Data<'a>`).Ideally we could take a generic generic associated type (I'm not evensure what to call that), but that's not something Rust has today.Overall this felt like a much simpler way of modeling `GetHost` and itsrequirements. This plumbed well throughout the WASIp3 work and thesignatures for concurrent functions felt much more appropriate in termsof complexity after this change. Taking this change to the limit meansthat `GetHost` in its entirety could be purged since all usages of itcould be replaced with `fn(&mut T) -> D::Data<'a>`, a hopefully muchmore understandable type.This change is not all rainbows however, there are some gotchas thatremain:* One is that all `add_to_linker` generated functions have a `D: HasData` type parameter. This type parameter cannot be inferred and must always be explicitly specified, and it's not easy to know what to supply here without reading documentation. Actually supplying the type parameter is quite easy once you know what to do (and what to fill in), but it may involve defining a small struct with a custom `HasData` implementation which can be non-obvious.* Another is that the `G: GetHost` value was previously a full Rust closure, but now it's transitioning to a function pointer. This is done in preparation for WASIp3 work where the function needs to be passed around, and doing that behind a generic parameter is more effort than it's worth. This means that embedders relying on the true closure-like nature here will have to update to using a function pointer instead.* The function pointer is stored in locations that require `'static`, and while `fn(T)` might be expected to be `'static` regardless of `T` is is, in fact, not. This means that practically `add_to_linker` requires `T: 'static`. Relative to just before this change this is a possible regression in functionality, but there orthogonal reasons beyond just this that we want to start requiring `T: 'static` anyway. That means that this isn't actually a regression relative to #10760, a related change.The first point is partially ameliorated with WASIp3 work insofar thatthe `D` type parameter will start serving as a location to specify whereconcurrent implementations are found. These concurrent methods don'ttake `&mut self` but instead are implemented for `T: HasData` types. Inthat sense it's more justified to have this weird type parameter, but inthe meantime without this support it'll feel a bit odd to have thislittle type parameter hanging off the side.This change has been integrated into the WASIp3 prototyping repositorywith success. This has additionally been integrated into the Spinembedding which has one of the more complicated reliances on`*_get_host` functions known. Given that it's expected that while thisis not necessarily a trivial change to rebase over it should at least bepossible.Finally the `HasData` trait here has been included with what I'm hopingis a sufficient amount of documentation to at least give folks a springboard to understand it. If folks have confusion about this `D` typeparameter my hope is they'll make their way to `HasData` which showcasesvarious patterns for "librarifying" host implementations of WITinterfaces. These patterns are all used throughout Wasmtime and WASIcurrently in crates and tests and such.* Update expanded test expectations List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

f81c0dc0 - Add `T: 'static` to `Store` (#10760)

Tue, 13 May 2025 05:08:32 +0000

Add `T: 'static` to `Store` (#10760)* Add `T: 'static` to `StoreSince the beginning the `T` type parameter on `Store` has had nobounds on it. This was intended for maximal flexibility in terms of whatembedders place within a `Store` and I've personally advocated thatwe need to keep it this way. In the development of the WASIp3 work,however, I've at least personally reached the conclusion that this is nolonger tenable and proceeding will require adding a `'static` bound todata within a store.Wasmtime today [already] carries unsafe `transmute`s to work around thislack of `'static` bound, and while the number of `unsafe` parts isrelatively small right now we're still fundamentally lying to thecompiler about lifetime bounds internally. With the WASIp3 async workthis degree of "lying" has become even worse. Joel has written up someexamples [on Zulip] about how the Rust compiler is requiring `'static`bounds in surprising ways. These patterns are cropping up quitefrequently in the WASIp3 work and it's becoming particularly onerousmaintaining all of the `unsafe` and ensuring that everything is in sync.In the WASIp3 repository I've additionally [prototyped a change] whichwould additionally practically require `T: 'static` in more locations.This change is one I plan on landing in Wasmtime in the near future andwhile its main motivations are for enabling WASIp3 work it is also amuch nicer system than what we have today, in my opinion.Overall the cost of not having `T: 'static` on `Store` is effectivelybecoming quite costly, in particular with respect to WASIp3 work. Thisis coupled with all known embedders already using `T: 'static` datawithin a `Store` so the expectation of the impact of this change isnot large. The main downside of this change as a result is that when andwhere to place `'static` bounds is sort of a game of whack-a-mole withthe compiler. For example I changed `Store` to require `'static`here, but the rest of the change is basically "hit compile until rustcsays it's ok". There's not necessarily a huge amount of rhyme-or-reasonto where `'static` bounds crop up, which can be surprising or difficultto work with for users.In the end I feel that this change is necessary and one we can't shyaway from. If problems crop up we'll need to figure out how to threadthat needle at that time, but I'm coming around to thinking that`T: 'static` is just a fundamental constraint we'll have to take on atthis time. Maybe a future version of Rust that fixes some of Joel'sexamples (if they can be fixed, we're not sure of that) we couldconsider relaxing this but that's left for future work.[already]: https://github.com/bytecodealliance/wasmtime/blob/35053d6d8d1a5d4692cf636cba0c920b4a79a44b/crates/wasmtime/src/runtime/store.rs#L602-L611[on Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.22type.20may.20not.20live.20long.20enough.22.20for.20generic.20closure/near/473862072[prototyped a change]: https://github.com/bytecodealliance/wasip3-prototyping/pull/158* Remove a no-longer-necessary `unsafe` block* Update test expectations* Fix gc-disabled builds List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

29d04b15 - Move the `GetHost` trait used in `bindgen!` into Wasmtime (#10746)

Wed, 07 May 2025 21:02:44 +0000

Move the `GetHost` trait used in `bindgen!` into Wasmtime (#10746)* Move the `GetHost` trait used in `bindgen!` into WasmtimeTurns out we don't actually need to generate this `GetHost` trait, wecan instead have it live in one location with extra documentation. Thereare already extra bounds on the `Host` associated type at all call-sitesso there's no need to additionally have trait bounds in the traitdefinition, meaning the trait definition is always the same and it canmove within Wasmtime.This shouldn't have any impact on any embedders today, it's just movingthings around.* Review comments List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

bb77f602 - wasmtime-wit-bindgen: Typecheck exports at {Foo}Indices construction (#10610)

Mon, 21 Apr 2025 21:54:01 +0000

wasmtime-wit-bindgen: Typecheck exports at {Foo}Indices construction (#10610)* wasmtime::component: make it possible to typecheck export funcs* wasmtime-wit-bindgen: add typechecking on construction of Indices struct* wit-bindgen: reduce to a single Indices constructor which takes InstancePre* bless bindgen output List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

af31e80d - wasmtime-wit-bindgen: emit a definition for all types in a wit interface (#10311)

Fri, 28 Feb 2025 19:06:58 +0000

wasmtime-wit-bindgen: emit a definition for all types in a wit interface (#10311)* wasmtime-wit-bindgen: emit a definition for all types in a witThe calculation of TypeInfo only reaches types which are passed to orfrom a function. For types which are not reachable, default to thedefining them according to the ownership setting given to bindgen.I have my doubts that `with`-reuse of bindgen types actually worksproperly when bindgen is set to Ownership::Borrowing but thats outof scope for this PR, which is to fix #10090* component-macro: bless bindgen test output List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

636435f1 - async/stream/future support for wasmtime-wit-bindgen (#10044)

Wed, 22 Jan 2025 17:19:46 +0000

async/stream/future support for wasmtime-wit-bindgen (#10044)* async/stream/future support for wasmtime-wit-bindgenI've split this out of #9582 to make review easier.This patch adds async/stream/future/error-context support to the host bindinggenerator, along with placeholder type and function definitions in the`wasmtime` crate which the generated bindings can refer to. Seehttps://github.com/dicej/rfcs/blob/component-async/accepted/component-model-async.md#componentbindgen-updatesfor the design and rationale.Note that I've added temporary `[patch.crates-io]` overrides in Cargo.toml untilhttps://github.com/bytecodealliance/wit-bindgen/pull/1130 andhttps://github.com/bytecodealliance/wasm-tools/pull/1978 have been released.Also note that we emit a `T: 'static` bound for `AsContextMut` whengenerating bindings with `concurrent_imports: true`. This is only because`rustc` insists that the closure we're passing to`LinkerInstance::func_wrap_concurrent` captures the lifetime of `T` despite mybest efforts to convince it otherwise. Alex and I suspect this is a limitationin the compiler, and I asked about it on the rust-lang Zulip, but we haven'tbeen able to determine a workaround so far.Signed-off-by: Joel Dice remove obsolete TODO commentSigned-off-by: Joel Dice make `futures` dep optionalSigned-off-by: Joel Dice update `wasm-tools` and `wit-bindgen`Signed-off-by: Joel Dice * run cargo vetSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

afd8bb39 - Add async example to bindgen_examples (#9822)

Fri, 20 Dec 2024 19:34:10 +0000

Add async example to bindgen_examples (#9822)* add async example* fix bindgen bug to make CI happySee https://github.com/bytecodealliance/wasmtime/pull/9822#issuecomment-2546851949* update test expectations* remove async_trait List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

d0a55990 - Remove async-trait in bindgen (#9867)

Fri, 20 Dec 2024 16:39:06 +0000

Remove async-trait in bindgen (#9867)* use trait_variant and async-func-in-trait instead of async-trait* remove all async_trait::async_trait related to bindgen! proc_macro* remove pub use async_trait::async_trait in __internal* bless `component-macro` tests to reflect `async_trait` removalSigned-off-by: Joel Dice * add `trait-variant` exemption to supply-chain/config.tomlThis exempts the `trait-variant` crate from vetting since it is published andmaintained by the rust-lang organization and is officially recommended by theRust project.Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice Co-authored-by: Joel Dice List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

2b29e459 - Use `tracing::Instrument` in generated bindings to avoid holding spans across await points (#9217)

Tue, 10 Sep 2024 00:22:36 +0000

Use `tracing::Instrument` in generated bindings to avoid holding spans across await points (#9217)* Use `tracing::Instrument` in generated bindings to avoid holding spansacross await pointsPreviously, if we had a WIT file with a functionasync-fn: func();then the generated code in `add_to_linker_get_host` would look likethis (if tracing is enabled and the function is async)inst.func_wrap_async( "my-func", move |mut caller: wasmtime::StoreContextMut<'_, T>, (): ()| { wasmtime::component::__internal::Box::new(async move { let span = tracing::span!( tracing::Level::TRACE, "wit-bindgen import", module = "test", function = "my-func", ); let _enter = span.enter(); tracing::event!(tracing::Level::TRACE, "call"); let host = &mut host_getter(caller.data_mut()); let r = Host::my_func(host).await; tracing::event!( tracing::Level::TRACE, result = tracing::field::debug(&r), "return" ); Ok(r) }) },)?;This keeps the tracing span active, even when the resulting future issuspended. The end result is that other unrelated tokio tasks running onthe same thread in the meantime will be shown as executing within the`wit-bindgen import` span.This commit changes the codegen to instead generateinst.func_wrap_async( "async-fn", move |mut caller: wasmtime::StoreContextMut<'_, T>, (): ()| { use tracing::Instrument; let span = tracing::span!( tracing::Level::TRACE, "wit-bindgen import", module = "test", function = "async-fn", ); wasmtime::component::__internal::Box::new( async move { tracing::event!(tracing::Level::TRACE, "call"); let host = &mut host_getter(caller.data_mut()); let r = Host::async_fn(host).await; tracing::event!( tracing::Level::TRACE, result = tracing::field::debug(&r), "return" ); Ok(r) } .instrument(span), ) },)?;Here, `tracing::Instrument` takes care of entering the span when thefuture is polled and exiting it when it is suspended.Fixes #9210* Bless expanded macro outputs List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

99d861cb - Expand the set of constructors of `bindgen!`-generated bindings (#9177)

Wed, 28 Aug 2024 16:36:26 +0000

Expand the set of constructors of `bindgen!`-generated bindings (#9177)* Expand the set of constructors of `bindgen!`-generated bindingsThis commit expands the set of supported constructors for `bindgen!`generated structures with the goal of bringing back`World::new(&mut store, instance)`. This method was removed previouslyin a refactoring to add `*Pre` structures but refactoring preexistingcode to use `*Pre` isn't always easy, so these extra generated bindingsprovide a smoother migration path for code from before.* Update test expectations List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

5393c2bf - Reduce typo count (#8951)

Mon, 15 Jul 2024 14:26:59 +0000

Reduce typo count (#8951) List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

f471b4dc - Refactor and document the wasmtime-wasi-http more (#8861)

Mon, 24 Jun 2024 15:24:58 +0000

Refactor and document the wasmtime-wasi-http more (#8861)* Improve some documentation of the `wasmtime-wasi` crateShow a few examples of using `with` to point to upstream `wasmtime-wasi`for bindings.* Refactor and document the `wasmtime-wasi-http` moreThis commit primarily adds a complete example of using`wasmtime-wasi-http` to the documentation. Along the way I've done anumber of other refactorings too:* `bindgen!`-generated `*Pre` structures now implement `Clone`.* `bindgen!`-generated `*Pre` structures now have an `engine` method.* `bindgen!`-generated `*Pre` structures now have an `instance_pre` method.* The structure of `wasmtime-wasi-http` now matches `wasmtime-wasi`, notably: * The `proxy` module is removed * `wasmtime_wasi_http::add_to_linker_{a,}sync` is the top level add-to-linker function. * The `bindings` module now contains `Proxy` and `ProxyPre` along with a `sync` submodule. * The `bindings` module contains all bindings for `wasi:http` things.* The `add_only_*` methods are un-hidden and documented.* Code processing `req` has been simplified by avoiding decomposing-and-reconstructing a request.* The `new_incoming_request` method is now generic to avoid callers having to do boxing/mapping themselves.* Update expanded macro expectations* Remove unused import List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

3171ef6d - Redesign how component exports work (#8786)

Tue, 18 Jun 2024 01:05:39 +0000

Redesign how component exports work (#8786)* Un-nest exports in a componentThis commit flattens the representation of exports in a component tomake them more easily indexable without forcing traversal through thehierarchy of instance imports/exports to get there.* Guarantee type information on component exportsDon't have it optional in some cases and present in others, insteadensure there's type information for all component exports immediatelyavailable.* Refactor how component instance exports are loadedThis commit is a change to Wasmtime's public API for`wasmtime::component::Instance` that reorganizes how component exportsare loaded. Previously there was a system where `Instance::exports()`was called that that was sort of "iterated over" in a builder-stylepattern to acquire the actual export desired. This required lifetimetrickery for nested instances and some unfortunate API bloat. The majordownside of this approach is that it requires unconditional stringlookups at runtime for exports and additionally does not serve as agreat place to implement the semver-compatible logic of #8395. The goalof this refactoring is to pave the way to improving this.The new APIs for loading exports now look a bit more similar to what'savailable for core modules. Notably there's a new`Component::export_index` method which enables performing a stringlookup and returning an index. This index can in turn be passed to`Instance::get_*` to skip the string lookup when exports are loaded. The`Instance::exports` API is then entirely removed and dismantled.The only piece remaining is the ability to load nested exports which isdone through an `Option` parameter to `Component::export_index`. Theway to load a nested instance is now to first lookup the instance with`None` as this parameter an then the instance itself is `Some` to lookup an export of that instance. This removes the need for arecursive-style lifetime-juggling API from wasmtime and in theory helpssimplify the usage of loading exports.* Update `bindgen!` generated structures for exportsThis commit updates the output of `bindgen!` to have a different setupfor exports of worlds to handle the changes from the previous commit.This introduces new `*Pre` structures which are generated alongside theexisting `Guest` structures for example. The `*Pre` versions contain`ComponentExportIndex` from the previous commit and serve as a path toaccelerating instantiation because all name lookups are skipped.* Update test expectations for `bindgen!`-generated output* Review comments* Fix doc link List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

3cd96e17 - Add `GetHost` to generated bindings for more flexible linking (#8448)

Mon, 13 May 2024 18:07:02 +0000

Add `GetHost` to generated bindings for more flexible linking (#8448)* Remove unused generated `add_root_to_linker` method* WIP: bindgen GetHost* Compile with Rust 1.78+Use as a guide of how to implement this by making the `GetHost` trait a bituglier.* Add an option to skip `&mut T -> T` implsAlso enable this for WASI crates since they do their own thing with`WasiView` for now. A future refactoring should be able to remove thisoption entirely and switch wasi crates to a new design of `WasiView`.* Update test expectations* Review comments* Undo temporary change* Handle some TODOs* Remove no-longer-relevant note* Fix wasmtime-wasi-http doc link---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs

eea68f59 - bindgen: Commit expanded bindgen output for tests (#8558)

Tue, 07 May 2024 00:58:19 +0000

bindgen: Commit expanded bindgen output for tests (#8558)These outputs are checked in and verified to be fresh by a test so thatthey can be relied on for code review. List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/dead-code_async.rs