You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The wasmtime CLI doesn't support labelled WASI imports or exports #14859
wasmtime run and wasmtime serve never call add_named_to_linker, so a component with a labelled WASI import, e.g. import env2: wasi:cli/environment@0.3.2; or a labelled wasi:http/client, fails to link:
component imports instance `env2`, but a matching implementation was not found in the linker
Labelled exports don't work either: export h: wasi:http/handler@0.3.0 under serve fails with a misleading no exported instance named 'wasi:http/incoming-handler@0.2.12', and a labelled wasi:cli/run export under run with no exported instance named 'wasi:cli/run@0.2.12'.
Some possible options:
bind every labelled WASI import to the default context (maybe behind something like -S named-imports),
I don’t have a concrete need for the CLI to bind labelled imports itself. But a labelled import fails with the generic “matching implementation was not found” (and also labelled exports). So preferably we either say explicitly that the CLI doesn’t support labelled (implements) imports/exports, in the error and/or docs, or we just make it work, e.g. by binding labelled WASI imports to the default context. I’m happy to send a PR for whichever you prefer.
Personally I'd err on the side of not doing anything here and just leaving this open. It's probably a nontrivial bit of infrastructure to add better error messages here at minimum and it's not clear that it's necessarily worth it just yet. Guests have to opt-in to named imports so the situation that this might arise is quite niche IMO. I don't think it makes sense to just bind to the default context because that sort of defeats the purpose of named imports in the first place
Activity
alexcrichton commentedon Oct 19, 2026
This is by design. Do you intend for this to be a feature request?
jrandolf commentedon Oct 19, 2026
I don’t have a concrete need for the CLI to bind labelled imports itself. But a labelled import fails with the generic “matching implementation was not found” (and also labelled exports). So preferably we either say explicitly that the CLI doesn’t support labelled (implements) imports/exports, in the error and/or docs, or we just make it work, e.g. by binding labelled WASI imports to the default context. I’m happy to send a PR for whichever you prefer.
alexcrichton commentedon Oct 19, 2026
Personally I'd err on the side of not doing anything here and just leaving this open. It's probably a nontrivial bit of infrastructure to add better error messages here at minimum and it's not clear that it's necessarily worth it just yet. Guests have to opt-in to named imports so the situation that this might arise is quite niche IMO. I don't think it makes sense to just bind to the default context because that sort of defeats the purpose of named imports in the first place