Repository navigation
Conversation
The `named_imports` option of `bindgen!` passes the host-chosen id to every generated method except the `convert_*` methods for `trappable_error_type`. These conversions can need the context for that id, though: converting the `stream-error` of `wasi:io/streams`, for example, pushes an `error` resource into a table, and with named imports the table is found through the id. This commit threads the id through to these conversions as well, matching all other methods of named-import traits, and updates the existing conversions in `wasmtime-wasi` and `wasmtime-wasi-http` accordingly. This is in preparation for supporting named imports of `wasi:io` interfaces. Part of bytecodealliance#14858
`wasmtime_wasi::p2::add_named_to_linker_async` didn't handle labelled imports
of `wasi:io/{error,poll,streams}`, so components importing these interfaces
under a label, such as composed components whose dependencies were isolated
from each other, failed to link.
This commit adds these interfaces to the `named_imports` bindings and to
`add_named_to_linker_async`. `wasi:io` has no state outside of the resource
table, so the implementations look up the table for the named import and
then defer to `wasmtime-wasi-io`.
`wasi:clocks/timezone` remains unsupported both with and without labels as
`wasmtime-wasi` doesn't implement it.
Part of bytecodealliance#14858
wasi:io in wasmtime-wasiwasi:io in wasmtime-wasi
|
I can't think of any reason a user might want to import wasi:io as a named import, or that an embedding would provide it as one. wasi:io is a singleton and so there being another instance of the same interface is nonsensical. In general I see the wasip2 interfaces and implementations as being "done" and only getting bug fixes, and we are focusing all our energy for new development on wasip3. So, in general, I would require significant description of a real use case motivating that any of wasmtime's implementations of the p2 interfaces should be made compatible with named imports, even if unlike wasi:io they aren't a special case that should always be singular. |
|
Actually, this was an example listed in the spec which is why I added it. I also do not think it's needed. I think we can close this if everyone is on the same page |
This builds on #14875, so only the last commit is new here.
wasmtime_wasi::p2::add_named_to_linker_asyncdidn't handle labelled imports ofwasi:io/{error,poll,streams}, so components importing them under a label, such as composed components whose dependencies are isolated from each other, failed to link. This adds them.wasi:iohas no state besides the resource table, so each method looks up the table for the import's context and callswasmtime-wasi-io.wasi:clocks/timezoneis still not covered, since wasmtime-wasi doesn't implement it at all.Part of #14858
LLM summary of the changes
Bindings (
wasi/src/p2/bindings.rs)wasi:io/{error,poll,streams}are added to thenamed_importsof the async bindings. They get the sameasync/trappable/tracingrules as inwasmtime-wasi-io. Without labels these interfaces are aliased towasmtime-wasi-iowithwith, so the rules only affect the named bindings. The resource types are the same as for unlabelled imports.Linking (
wasi/src/p2/mod.rs)InterfacegetsIoError,IoPollandIoStreams, andadd_named_to_linker_with_options_asyncadds the three interfaces through a newHasIoNameddata type.Implementation (
wasi/src/p2/host/io.rs)Each method of
error,pollandstreamslooks upctx(id).tableand calls the correspondingwasmtime-wasi-iomethod, includingconvert_stream_error, which needs the id from #14875. As documented for named WASI contexts, a stream created through one label and used through another only works if their contexts share aResourceTable.Test (
wasi/tests/all/p2)A component imports
wasi:cli/stdoutand thewasi:iointerfaces it uses under labels, and checks that output goes to the labelled context's stdout. It's written in WAT because a labelledwasi:cli/stdoutusing types from labelledwasi:ioimports can't be written in WIT.