Stream: git-wasmtime

Topic: wasmtime / PR #13513 Finish bindings generation for `(imp...

Wasmtime GitHub notifications bot (May 29 2026 at 22:05):

alexcrichton opened PR #13513 from alexcrichton:finish-implements to bytecodealliance:main:

This commit is the final step in finishing up the bindings generation story for bindgen! w.r.t. the (implement ...) component model feature. Namely bindgen! now has the option named_imports: { ... } which generates a new top-level named_imports module with nested modules within it. These nested modules are similar to the default-generated ones except that they additionally take an extra "id" parameter in all trait methods. The add_to_linker function additionally takes both a &Component and a lookup function.

Putting all this together the expected flow is:

• Host decide they want to accept any number of import a: b:c/d; from components at runtime. Bindings are generated with named_imports: { ... } in the bindgen! invocation.

• Hosts switch from linker-per-engine to instead using a linker-per-component. After the typical population of items within the Linker next the host uses the named_imports::b::c::d::add_to_linker, for example. Here the host performs lookup from whatever string was found in the component to an ID key that the host knows about. Upon success this key will be closed over in all add_to_linker functions. Upon failure the add_to_linker closure fails.

• This per-component linker is used to instantiate and create instances as usual. At runtime when a named import is invoked the closed-over ID is passed to the trait implementation as a parameter. Hosts can thus disambiguate through which interface the component made a call through.

Some light tests are added throughout this showcasing the various capabilities. This notably added a new ComponentExtern::is_implements method to peform semver-matching automatically so hosts can generate bindings with one version and still accept implements with other slightly different but compatible versions.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (May 29 2026 at 22:05):

alexcrichton requested pchickey for a review on PR #13513.

Wasmtime GitHub notifications bot (May 29 2026 at 22:05):

alexcrichton requested wasmtime-core-reviewers for a review on PR #13513.

Wasmtime GitHub notifications bot (May 29 2026 at 23:05):

github-actions[bot] added the label wasmtime:api on PR #13513.

Wasmtime GitHub notifications bot (May 29 2026 at 23:16):

tschneidereit commented on PR #13513:

• Hosts switch from linker-per-engine to instead using a linker-per-component.

One thing I didn't think about when we discussed this yesterday: how much overhead does this introduce for hosts with large numbers of components loaded? (I'm not sure how much of a real alternative to this design there is, but I'd at least like to understand the costs a bit better.)

Last updated: Jun 01 2026 at 09:49 UTC