Stream: git-wasmtime

Topic: wasmtime / PR #14868 Improve docs and tests for implements

Wasmtime GitHub notifications bot (Oct 19 2026 at 21:59):

jrandolf opened PR #14868 from jrandolf:implements-docs-tests to bytecodealliance:main:

This fixes docs around implements and named imports that had drifted from the implementation, and adds tests for paths that had no coverage.

Docs:

• ComponentExternData::implements said it's used to match imports by interface name, but imports are only resolved by their own name.
• The bindgen! named_imports docs said the id is passed by reference and that interfaces with resources aren't supported. Neither is true anymore. They now also explain how labelled imports are bound with and without named_imports.
• The WASI named views (WasiNamedView, WasiHttpNamedView and the per-interface ones) said their ResourceTable doesn't need to be shared. It has to be the default context's table, because resources flow between named and plain interfaces; for example, a stream from a named wasi:cli/stdout is used through wasi:io/streams.
• The config and CLI flag docs now mention external-id next to implements, and a few typos are fixed.

Tests:

• The bindgen! implements test now actually puts (implements ...) on its imports. Before, they were plain imports.
• An interface exported twice under different labels, called through bindgen!.
• The Linker resolves a labelled import only by its label, never by the interface it implements (and vice versa), and two labels get separate definitions.
• Semver edge cases for ComponentExtern::is_implements.
• Loading a precompiled component that uses implements into an engine with the feature disabled fails, and external-id is rejected when the feature is disabled.

None of the new tests found a bug. I checked that each one fails against a deliberately broken implementation.

Closes #14857

Wasmtime GitHub notifications bot (Oct 19 2026 at 22:03):

jrandolf has marked PR #14868 as ready for review.

Wasmtime GitHub notifications bot (Oct 19 2026 at 22:03):

jrandolf removed the review request for wasmtime-wasi-reviewers from PR #14868.

Wasmtime GitHub notifications bot (Oct 19 2026 at 22:03):

jrandolf requested rvolosatovs for a review on PR #14868.

Wasmtime GitHub notifications bot (Oct 19 2026 at 22:03):

jrandolf requested wasmtime-wasi-reviewers for a review on PR #14868.

Wasmtime GitHub notifications bot (Oct 19 2026 at 22:03):

jrandolf removed the review request for wasmtime-core-reviewers from PR #14868.

Wasmtime GitHub notifications bot (Oct 19 2026 at 22:03):

jrandolf requested pchickey for a review on PR #14868.

Wasmtime GitHub notifications bot (Oct 19 2026 at 22:03):

jrandolf requested wasmtime-core-reviewers for a review on PR #14868.

Wasmtime GitHub notifications bot (Oct 20 2026 at 01:09):

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

Wasmtime GitHub notifications bot (Oct 20 2026 at 01:09):

github-actions[bot] added the label wasi on PR #14868.

Wasmtime GitHub notifications bot (Oct 20 2026 at 01:09):

github-actions[bot] added the label wasmtime:config on PR #14868.

Wasmtime GitHub notifications bot (Oct 20 2026 at 01:55):

github-actions[bot] commented on PR #14868:

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• [ ] If you added a new Config method, you wrote extensive documentation for
  it.

  <details>

  Our documentation should be of the following form:

  ```text
  Short, simple summary sentence.

  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.

  Is this method fallible? If so, when can it return an error?

  Can this method panic? If so, when does it panic?

  Example

  Optional example here.
  ```

  </details>

• [ ] If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  <details>

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See [our docs on fuzzing][fuzzing-docs] for more details.

  </details>

• [ ] If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html

---

<details>

To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.

To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.

Learn more.

</details>

Wasmtime GitHub notifications bot (Oct 20 2026 at 17:03):

:speech_balloon: alexcrichton created PR review comment:

Is there any particular reason to test the deserialize behavior vs assuming it works?

Wasmtime GitHub notifications bot (Oct 20 2026 at 17:03):

:speech_balloon: alexcrichton created PR review comment:

If this is true, this might be a bug -- separate imports are supposed to get separate traits. Lacking this option means that the host can only load the WIT of the shape that was passed in to bindgen!, and the presence of this option means that the host can load components with a variety of shapes of WIT (e.g. arbitrary named keys). -- I think this is the important distinction to make here, if at all.

Wasmtime GitHub notifications bot (Oct 20 2026 at 17:03):

:speech_balloon: alexcrichton created PR review comment:

Are you sure this isn't already tested? IIRC this was added when I first added implements support (or at some point)

Wasmtime GitHub notifications bot (Oct 20 2026 at 17:03):

:speech_balloon: alexcrichton created PR review comment:

Are these added tests really necessary? What is the value added with these new tests?

Wasmtime GitHub notifications bot (Oct 20 2026 at 17:03):

:speech_balloon: alexcrichton created PR review comment:

Why is "(including resource destructors)" necessary here?

Wasmtime GitHub notifications bot (Oct 20 2026 at 17:03):

:memo: alexcrichton submitted PR review:

I'd ask you to please be judicious when adding tests for tests sake. There's an infinite amount of things we could test but we have limited CI resources. It's not worth it to test everything possible, so tests need to carry their weight beyond "seems good".

Wasmtime GitHub notifications bot (Oct 20 2026 at 17:03):

:speech_balloon: alexcrichton created PR review comment:

I think the wording here (and replicated elsewhere) is a bit too strong. While I think it's worthwhile to say that it's recommended that there's only one table it's not strictly required. For example wasi:clocks can work with separate tables I believe due to the resource types being part of the interfaces.

Could this (and other blocks) be re-worded to say that a single table is strongly recommended, but not required in all situations?

Wasmtime GitHub notifications bot (Oct 20 2026 at 17:04):

alexcrichton removed the review request for rvolosatovs from PR #14868.

Wasmtime GitHub notifications bot (Oct 20 2026 at 17:04):

alexcrichton removed the review request for pchickey from PR #14868.

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

jrandolf commented on PR #14868:

Makes sense, I've trimmed the tests down.

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:memo: jrandolf submitted PR review.

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:speech_balloon: jrandolf created PR review comment:

Done

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:memo: jrandolf submitted PR review.

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:speech_balloon: jrandolf created PR review comment:

Done

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:memo: jrandolf submitted PR review.

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:speech_balloon: jrandolf created PR review comment:

I've replaced that paragraph with the distinction you describe. I'm also going to check what the bindings generate today for several labels without named_imports, and follow up if it is a bug.

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:memo: jrandolf submitted PR review.

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:speech_balloon: jrandolf created PR review comment:

Done

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:memo: jrandolf submitted PR review.

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:speech_balloon: jrandolf created PR review comment:

Done

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:speech_balloon: jrandolf created PR review comment:

Done

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

:memo: jrandolf submitted PR review.

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:58):

jrandolf edited PR #14868:

This fixes docs around implements and named imports that had drifted from the implementation:

• ComponentExternData::implements said it's used to match imports by interface name, but imports are only resolved by their own name.
• The bindgen! named_imports docs said the id is passed by reference and that interfaces with resources aren't supported. Neither is true anymore. They now also say what the option makes possible: loading components that import the listed interfaces under any names.
• The WASI named views (WasiNamedView, WasiHttpNamedView and the per-interface ones) said their ResourceTable doesn't need to be shared with the default context. Resources can flow between named and plain interfaces, for example a stream from a named wasi:cli/stdout is used through wasi:io/streams, so sharing it is now strongly recommended.
• The config and CLI flag docs now mention external-id next to implements, and a few typos are fixed.

It also fixes the bindgen! implements tests, whose component didn't actually annotate its imports with (implements ...), and checks that external-id is rejected when the feature is disabled.

Closes #14857

Wasmtime GitHub notifications bot (Oct 20 2026 at 19:00):

jrandolf edited a comment on PR #14868:

I've trimmed the tests down.

Wasmtime GitHub notifications bot (Oct 20 2026 at 19:01):

:speech_balloon: jrandolf edited PR review comment.

Wasmtime GitHub notifications bot (Oct 20 2026 at 19:01):

:speech_balloon: jrandolf edited PR review comment.

Wasmtime GitHub notifications bot (Oct 20 2026 at 19:08):

jrandolf updated PR #14868.

Wasmtime GitHub notifications bot (Oct 20 2026 at 19:59):

:thumbs_up: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Oct 20 2026 at 19:59):

alexcrichton added PR #14868 Improve docs and tests for implements to the merge queue.

Wasmtime GitHub notifications bot (Oct 20 2026 at 20:42):

:check: alexcrichton merged PR #14868.

Wasmtime GitHub notifications bot (Oct 20 2026 at 20:42):

alexcrichton removed PR #14868 Improve docs and tests for implements from the merge queue.

Wasmtime GitHub notifications bot (Oct 20 2026 at 22:47):

:memo: jrandolf submitted PR review.

Wasmtime GitHub notifications bot (Oct 20 2026 at 22:47):

:speech_balloon: jrandolf created PR review comment:

I checked: it is the case today, and it's by design from #13497. I think it also matches the spec's intent for hosts: the guest gets distinct per-label names, while the host can serve every label with one implementation parameterized by the label, which is what named_imports provides. Different backends per label are still possible with add_to_linker_instance. So I've left it as is, and the docs now describe the distinction you mentioned.

Last updated: Oct 31 2026 at 23:03 UTC