Stream: git-wasmtime

Topic: wasmtime / PR #14372 Add `canonical_names` to wit-bindgen

Wasmtime GitHub notifications bot (Sep 21 2026 at 23:00):

chenyan2002 opened PR #14372 from chenyan2002:canon-ver to bytecodealliance:main:

Part of https://github.com/bytecodealliance/wasmtime/issues/14346

Add canonical_names flag to wit-bindgen. When both guest and host enable canonical names, the linker should work by string matching.

Eventually, we will enable this in wasmtime-wasi, but that requires changes to NameMap, which will be a future PR.

Wasmtime GitHub notifications bot (Sep 21 2026 at 23:00):

chenyan2002 requested pchickey for a review on PR #14372.

Wasmtime GitHub notifications bot (Sep 21 2026 at 23:00):

chenyan2002 requested wasmtime-core-reviewers for a review on PR #14372.

Wasmtime GitHub notifications bot (Sep 21 2026 at 23:04):

:memo: Voyagerroc-Lab submitted PR review:

Review summary

The new canonical_names option is threaded through macro parsing, generated linker world names, generated interface IDs, and the runtime linker helper. The added end-to-end test exercises a canonicalized imported interface against a component whose import uses the canonical version and verifies the host call result.

One coverage gap remains: the test does not exercise an exported interface name or a world with a versioned exported interface, although interface_id_of is also changed for that path. Please consider adding that case before treating the option as fully covered. This is not a blocking issue for the imported-interface behavior covered here.

Wasmtime GitHub notifications bot (Sep 22 2026 at 14:32):

alexcrichton commented on PR #14372:

Thinking more on the original issue, personally I don't think that this is the best way to go to integrate the canonical-names feature. I alluded to this a bit in my comment on #14346 but I don't think the bindgen! option makes sense here because embedders don't have an answer of whether to use it or not, especially during a transition period. I think it'd be best to support this entirely within NameMap and that way bindings are always "full version" and the NameMap handles everything else.

Wasmtime should still gate loading components with canonical names based on the Config feature (as it already does), but after that everything in the runtime can basically assumed it's turned on so NameMap can just change to assuming canonical-names should always work.

Wasmtime GitHub notifications bot (Sep 22 2026 at 18:28):

chenyan2002 commented on PR #14372:

I agree, during the transition period, NameMap is the only place that needs to change. But after the transition period (probably after a long time), I expect NameMap to be just a regular HashMap without the alternative_look_up. And we expect that the host API to have canonical names as well. Do you expect that canonicalized_id_of and id_of would merge at some point, so that this change can happen automatically?

Another use case is when using wasmtime as a library, and providing our own host APIs, we can enable canonical names for both host and guest at the same time, so that linking only relies on string equality. This feels simpler than relying on the bi-directional map from NameMap.

Wasmtime GitHub notifications bot (Sep 22 2026 at 20:57):

alexcrichton commented on PR #14372:

Maybe in the super long-term yeah, but for the medium-term we'll want today's components with non-canonical names to continue to work. That may not require the full implementation within NameMap today, but alternative_look_up will need to stick around in one form or another. Over time though I agree that this PR would be landed and happen unconditionally with no way to turn off once we're confident in the various changes to NameMap and impact on the host. For embedders, that makes sense, yeah, but we'd still have to in this repository make a decision for WASI APIs which doesn't feel great.

Overall my opinion is that there shouldn't be a canonical-names option on the host side. To implement that I'd see 2 ways to do so:

1. First is what I've described where bindgen! does full versions and NameMap handles everything internally.
2. Alternatively this PR would land un-gated where everything is defined with a canonical key and NameMap would handle queries of full versions to as-if they looked up the canonical key

I don't have a preference either way myself, and (2) is more future-facing yeah so might make sense.

Wasmtime GitHub notifications bot (Oct 01 2026 at 02:10):

:cross_mark: chenyan2002 closed without merge PR #14372.

Last updated: Oct 11 2026 at 04:10 UTC