Repository navigation
Limitations of the named_imports lookup API #14860
Description
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 theComponentExternwould cover it. - The lookup can't decline an import: returning
Erraborts linking, so an embedder can't leave a particular label to be defined some other way. Something likeResult<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"), andwith: { "a": .. }for a label reports a misleading "not referenced in the target world" error.
Activity
alexcrichton commentedon Oct 19, 2026
@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
jrandolf commentedon Oct 19, 2026
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 😅 (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.
alexcrichton commentedon Oct 19, 2026
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)
jrandolf commentedon Oct 19, 2026
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 😅.
Rework the `named_imports` lookup in bindgen!
Rework the `named_imports` lookup in bindgen!
Rework the `named_imports` lookup in bindgen!
Rework the `named_imports` lookup in bindgen!