wasmtime / issue #14860 Limitations of the named_imports ... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #14860 Limitations of the named_imports ...

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

A few limitations of the named_imports lookup API generated by bindgen! (and used by the WASI crates):

The lookup only receives the import name. external-id, which the spec describes as telling the host how to supply an import, is never passed along. Passing the ComponentExtern would cover it.

The lookup can't decline an import: returning Err aborts linking, so an embedder can't leave a particular label to be defined some other way. Something like Result<Option<Id>> would allow that.

Tracing spans for calls through different labels are identical (module="store" function="get"), with no label or id.

Per-function rule keys are inconsistent: labelled imports need interface keys ("foo:foo/store.get") while labelled exports need label keys ("c.greet"), and with: { "a": .. } for a label reports a misleading "not referenced in the target world" error.

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

alexcrichton commented on issue #14860:

@jrandolf do you have a need for any of these issues to be resolved? If not, please don't use the issue tracker as a dumping ground for all LLM-found things and double-check you're following our LLM policy

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

jrandolf commented on issue #14860:

Sorry about that! I know this is a lot of issues but I am reading and writing these manually. I was actually concerned I was overloading maintainers :sweat_smile: (which it seems might be the case).

The reason we opened these is to build a concrete path toward stability for 0.3.2. Our company is working toward implementing this but we much prefer to upstream and help wasmtime then doing this in a fork.

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

jrandolf edited a comment on issue #14860:

Sorry about that! I know this is a lot of issues but I am reading and writing these manually. I was actually concerned I was overloading maintainers :sweat_smile: (which it seems might be the case).

The reason we opened these is to build a concrete path toward stability for 0.3.2. Our company is working toward implementing this but we much prefer to upstream and help wasmtime than doing this in a fork.

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

jrandolf edited a comment on issue #14860:

Sorry about that! I know this is a lot of issues but I am reading and writing these manually (with the help of AI). I was actually concerned I was overloading maintainers :sweat_smile: (which it seems might be the case).

The reason we opened these is to build a concrete path toward stability for 0.3.2. Our company is working toward implementing this but we much prefer to upstream and help wasmtime than doing this in a fork.

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

jrandolf edited a comment on issue #14860:

Sorry about that! I know this is a lot of issues but I am reading and writing these manually (with the help of AI). I was actually concerned I was overloading maintainers :sweat_smile: (which it seems might be the case).

The reason we opened these is to build a concrete path toward stability for 0.3.2. Our company is working toward implementing this but we much prefer to upstream and help wasmtime than doing this in a fork.

P.S. We only file issues that we intend to upstream a PR about. If you'd prefer that we upstream a PR rather than doing both, we can do that instead.

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

alexcrichton commented on issue #14860:

Ok makes sense, and yeah there's quite a lot here so if you wouldn't mind doing a pass to consolidate that might make sense -- for example maybe lumping things together where appropriate or one tracking issue in the future. For now it's ok to leave the issues as-is. If you'd prefer, though, we have no policy about an issue existing before a PR, so it's also fine to just track things internally and then send a PR if you've got a fix.

And, finally, there's also no need to having 100% of all issues addressed for when we turn a feature on, it's often the case that there are known issues we subjectively feel are too niche to block things. In that sense it's not that everything needs fixing, but everything probably does at least need a decision of whether it's blocking or not (defaulting to blocking until we determine otherwise)

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

alexcrichton added the wasm-proposal:component-model-implements label to Issue #14860.

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

jrandolf commented on issue #14860:

Thanks for understanding and again I'm really sorry about this! We also maintain a few repos and found how it's problematic to have LLMs dump issues :sweat_smile:.

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

jrandolf commented on issue #14860:

We don't have a concrete need for this, so I'm closing it.

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

jrandolf closed issue #14860:

A few limitations of the named_imports lookup API generated by bindgen! (and used by the WASI crates):

The lookup only receives the import name. external-id, which the spec describes as telling the host how to supply an import, is never passed along. Passing the ComponentExtern would cover it.

The lookup can't decline an import: returning Err aborts linking, so an embedder can't leave a particular label to be defined some other way. Something like Result<Option<Id>> would allow that.

Tracing spans for calls through different labels are identical (module="store" function="get"), with no label or id.

Per-function rule keys are inconsistent: labelled imports need interface keys ("foo:foo/store.get") while labelled exports need label keys ("c.greet"), and with: { "a": .. } for a label reports a misleading "not referenced in the target world" error.

Last updated: Oct 31 2026 at 23:03 UTC