Stream: git-wasmtime

Topic: wasmtime / PR #14746 Add component support for unknown im...

Wasmtime GitHub notifications bot (Oct 14 2026 at 17:30):

fitzgen opened PR #14746 from fitzgen:define-unknown-imports-for-components to bytecodealliance:main:

Core Wasm modules could already do this, but components couldn't. The wrinkle is that we don't currently have a way to implement default values for future, stream, and error-context types. For now, those become traps instead of default values, but I could foresee e.g. creating a host API for making streams of a dynamic T type and creating a /dev/null-style stream for the default stream.

<!--
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 review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.md

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

Wasmtime GitHub notifications bot (Oct 14 2026 at 17:30):

fitzgen requested alexcrichton for a review on PR #14746.

Wasmtime GitHub notifications bot (Oct 14 2026 at 17:30):

fitzgen requested wasmtime-core-reviewers for a review on PR #14746.

Wasmtime GitHub notifications bot (Oct 14 2026 at 17:48):

:speech_balloon: alexcrichton created PR review comment:

This function might make more sense to take impl AsContextMut which means that this could be implemented? Otherwise this'll always be impossible to implement

Wasmtime GitHub notifications bot (Oct 14 2026 at 17:48):

:memo: alexcrichton submitted PR review:

In theory adding future/stream support shouldn't be too too hard -- a default stream is always empty and a default future immediately produces its default value. If you'd prefer to defer though that seems fine.

Otherwise though this'll want some more special handling w.r.t. resources. In addition to the types lining up I mention below you'll also want non-trapping stubs to delete any resources found in the arguments. For example borrows given to the host need to be dropped lest that causes a trap of "borrows remain when returning" when the host returns.

Wasmtime GitHub notifications bot (Oct 14 2026 at 17:48):

:speech_balloon: alexcrichton created PR review comment:

I don't think that this will work -- this needs to create a resource of the correct type to pass the type-check of resources flowing back into the guest. I'm not entirely sure if we have the public API for that, but DefaultResult::Resource will likely need a payload with the type of the resource being created.

Wasmtime GitHub notifications bot (Oct 14 2026 at 18:16):

:memo: fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Oct 14 2026 at 18:16):

:speech_balloon: fitzgen created PR review comment:

I would prefer to push this to a follow up, because I don't think we even have an API for a host to create a StreamAny type thing?

Wasmtime GitHub notifications bot (Oct 14 2026 at 18:28):

:memo: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Oct 14 2026 at 18:28):

:speech_balloon: alexcrichton created PR review comment:

Right yeah good point. We can convert StreamReader<T> into StreamAny, but that means we have to statically know T which isn't possible here. That being said though taking AsContextMut would make this implementable for resources I believe, at least host-defined ones

Wasmtime GitHub notifications bot (Oct 14 2026 at 18:28):

:memo: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Oct 14 2026 at 18:28):

:speech_balloon: alexcrichton created PR review comment:

(but deferring is still fine of course)

Wasmtime GitHub notifications bot (Oct 14 2026 at 20:27):

fitzgen updated PR #14746.

Wasmtime GitHub notifications bot (Oct 14 2026 at 20:28):

fitzgen commented on PR #14746:

Added a store context parameter and cleaned things up a bit. Still no streams/futures, will look into that in a follow up.

Wasmtime GitHub notifications bot (Oct 14 2026 at 21:49):

:memo: alexcrichton submitted PR review:

To confirm: can you test whether this method works with polyfilling APIs that have a borrow resource as an argument? For example a method on a resource -- I'd expect that this implementation will not work because it's not destroying the arguments meaning that the borrows are always leftover at the end of the call and would always trap-on-return

Wasmtime GitHub notifications bot (Oct 14 2026 at 21:49):

:speech_balloon: alexcrichton created PR review comment:

This'll want to validate ty I think to ensure that it only works with host-defined types. It's semantically not really possible to synthesize a guest resource in default_value, so that'll have to just unconditionally return an error saying "sorry, can't do that".

Wasmtime GitHub notifications bot (Oct 15 2026 at 01:07):

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

Wasmtime GitHub notifications bot (Oct 15 2026 at 01:07):

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

Wasmtime GitHub notifications bot (Oct 15 2026 at 15:18):

fitzgen updated PR #14746.

Wasmtime GitHub notifications bot (Oct 15 2026 at 15:19):

:memo: fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Oct 15 2026 at 15:19):

:speech_balloon: fitzgen created PR review comment:

Done

Wasmtime GitHub notifications bot (Oct 15 2026 at 15:48):

fitzgen updated PR #14746.

Wasmtime GitHub notifications bot (Oct 15 2026 at 15:48):

fitzgen commented on PR #14746:

To confirm: can you test whether this method works with polyfilling APIs that have a borrow resource as an argument? For example a method on a resource -- I'd expect that this implementation will not work because it's not destroying the arguments meaning that the borrows are always leftover at the end of the call and would always trap-on-return

Good catch, this did indeed fail, and I've pushed a commit that drops handles now, and added tests for this scenario.

Wasmtime GitHub notifications bot (Oct 15 2026 at 20:44):

:thumbs_up: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Oct 15 2026 at 20:44):

:speech_balloon: alexcrichton created PR review comment:

This is I think overkill for here - we've got validation checks in place to bound the depth of a type hierarchy reasonable meaning that the host shouldn't blow its stack handling anything naturally. That plus Drop for Val is already recursive anyway and has no special handling.

Wasmtime GitHub notifications bot (Oct 15 2026 at 20:44):

:speech_balloon: alexcrichton created PR review comment:

This should still drop futures/streams because otherwise it's basically akin to a memory leak in the store

Wasmtime GitHub notifications bot (Oct 15 2026 at 20:44):

:speech_balloon: alexcrichton created PR review comment:

I'm realizing on re-reading this (sorry didn't notice this earlier) -- but like above I think the on-heap stack is probably overkill here given the validation we already have about type depth.

Wasmtime GitHub notifications bot (Oct 15 2026 at 20:44):

:speech_balloon: alexcrichton created PR review comment:

Along the line of previous comments, I think it's fine to drop this test since we have a ton of "near the limit" we don't test anywhere else and we rely on the validation check to avoid the need to test

Wasmtime GitHub notifications bot (Oct 15 2026 at 20:44):

:speech_balloon: alexcrichton created PR review comment:

In general as LLMs are relatively good at writing tests I'm a bit wary of adding hundreds of lines per test per change as we'll quickly get to the point that the test suite basically can't be compiled in any reasonable amount of time (it's already quite large). To that extent could tests perhaps be combined and/or shuffled around here? For example tests that cli_tests.rs run are generally quicker to both compile and run insfoar as compiling running a few Commands is not too taxing for rustc. Most of the tests here I think are probably implementable with CLI flags an --run and asserting over the output I think too.

Mostly though mind looking into trying to reduce the testing overhead here?

Wasmtime GitHub notifications bot (Oct 15 2026 at 23:03):

fitzgen updated PR #14746.

Wasmtime GitHub notifications bot (Oct 15 2026 at 23:03):

fitzgen has enabled auto merge for PR #14746.

Wasmtime GitHub notifications bot (Oct 16 2026 at 16:10):

fitzgen updated PR #14746.

Wasmtime GitHub notifications bot (Oct 16 2026 at 16:28):

fitzgen added PR #14746 Add component support for unknown imports returning default values to the merge queue.

Wasmtime GitHub notifications bot (Oct 16 2026 at 16:51):

:check: fitzgen merged PR #14746.

Wasmtime GitHub notifications bot (Oct 16 2026 at 16:51):

fitzgen removed PR #14746 Add component support for unknown imports returning default values from the merge queue.

Last updated: Oct 31 2026 at 23:03 UTC