Link guests importing semver-compatible interface versions by andreaTP · Pull Request #69 · roastedroot/endive-cm

andreaTP · 2026-10-20T16:04:36Z

Guests built by real toolchains import older patch versions of WASI interfaces, for example Rust 1.96's std imports wasi:io/poll@0.2.6, while our host provides @0.2.12. Import names were matched exactly, so linking failed.

This resolves host-provided imports by the Component Model's canonical interface name rule, the same one Wasmtime (alternate_lookup_key) and jco use:

An exact name always wins.
Otherwise the version is cut after the major (@1.2.3 → @1) or, for 0.x, after the minor (@0.2.6 → @0.2), and the highest provided version with the same key is used. Versions are compared numerically.
0.0.x, pre-releases and unversioned names only match exactly. Build metadata is ignored, and two candidates that differ only in it fail as ambiguous.
It applies only at the host boundary. Nested instantiation stays exact.
The existing structural type check still runs, so a host missing a function or providing a mistyped one is rejected. The error then names both the requested and the supplied name.

Not included: export-side matching, bindgen version selection (the first half of #53), and parsing the versionsuffix attribute.

Tests: InterfaceVersionsTests (48) and CompatibleVersionImportTests (20). Refs #53.

jeremyg484

Looks great!

Phoenixxo

Overall, looks good. Just some simplifications that might be better to keep in mind

Phoenixxo · 2026-10-20T23:08:05Z

+            Map.Entry<String, Object> resolved = builder.instance().resolveImport(imp.name());
+            try {
+                processImport(builder, imp, resolved);
+            } catch (LinkageException e) {
+                if (resolved == null || resolved.getKey().equals(imp.name())) {
+                    throw e;
+                }


resolveImport now runs for every import before the kind-specific code. An ambiguous set of host names fails the link even when the import wouldn’t have used a host value. An eq-bound type import or an instance type that demands nothing is synthesized when nothing is supplied, and it used to link regardless of what else the host provided. I think raising the ambiguity error only on the paths that consume the value would be best here.

With this change a compatible host name counts as supplied for every kind, so an eq-bound type or a demand-nothing instance that finds one checks it the same way it would check an exact name. With two candidates tied on version there's no single value to check, and falling back to the synthesized one would quietly ignore both. It also takes a host that registers two names differing only in build metadata, which I'd rather report than work around. Happy to revisit if you have a real case.

Phoenixxo · 2026-10-20T23:12:43Z

+                processImport(builder, imp, resolved);
+            } catch (LinkageException e) {
+                if (resolved == null || resolved.getKey().equals(imp.name())) {
+                    throw e;


Small nitpick, but I think the rethrown exception puts e.getMessage() in its own message and also passes e as the cause, so the original text shows up twice in a stack trace.

This follows the existing wrap at ComponentLinker.java:107. Keeping the reason in the message lets callers that only log getMessage() see it, and the cause keeps the frames where the mismatch was found.

Phoenixxo · 2026-10-20T23:33:42Z

+    static String resolve(String requested, Collection<String> provided) {
+        if (provided.contains(requested)) {
+            return requested;
+        }
+        String key = compatibleKey(requested);
+        if (key == null) {
+            return null;
+        }
+        Version best = null;
+        Version tied = null;
+        for (String name : provided) {
+            Version candidate = Version.parse(name);
+            if (candidate == null || !candidate.key.equals(key)) {
+                continue;
+            }
+            int order = best == null ? 1 : PRECEDENCE.compare(candidate, best);
+            if (order > 0) {
+                best = candidate;
+                tied = null;
+            } else if (order == 0) {
+                tied = candidate;
+            }
+        }
+        if (tied != null) {
+            throw new LinkageException(
+                    "Import \""
+                            + requested
+                            + "\" is ambiguous between \""
+                            + best.name
+                            + "\" and \""
+                            + tied.name
+                            + "\", which differ only in build metadata");
+        }
+        return best == null ? null : best.name;
+    }


When there’s no exact match, resolve will run the semver regex over every provided name, and it does this for each import. A host with a few dozen WASI interfaces and a guest importing most of them at an older patch means well over a thousand matches per link. We could move to using an index on the host names by compatible key once, in addImports or lazily on first lookup, which would make each import a single map lookup.

Good catch. Older patch versions are exactly what Rust guests import, so every WASI import took the scan. Host names are now indexed by compatible key once per instantiation, lazily on the first lookup that misses an exact name, and each import is one map lookup. 3933ee7

Phoenixxo · 2026-10-20T23:35:43Z

+     */
+    Map.Entry<String, Object> resolveImport(String name) {
+        String supplied;
+        if (parent == null) {


parent == null repeats the check in ComponentLinker.atHostBoundary. If the definition of the host boundary ever changes, the two could disagree, so version matching and the host-only type checks would no longer apply at the same level. Can both go through one method?

Moved to ComponentInstance.atHostBoundary(). The linker uses it everywhere now, including the parent() == null check that was already in processComponentImport. 67237ef

Phoenixxo · 2026-10-20T23:36:55Z

-                default:
-                    throw new LinkageException(
-                            "Import type " + imp.externDesc().kind() + " not supported yet");
+            Map.Entry<String, Object> resolved = builder.instance().resolveImport(imp.name());


This adds a Map.Entry parameter to five process*Import methods and allocates an entry per import, but the key is only used to build the error message in the catch block. Wouldn't it be simpler to resolve to the supplied name and read the value from the instance, or to keep the supplied name in one place for the error path?

The process*Import signatures are back to what they were. hasImport/getImport resolve compatible names at the host boundary, and processImportSection keeps the supplied name only to word the error. 67237ef

…e host boundary in one place

andreaTP · 2026-10-21T10:27:35Z

@Phoenixxo I addressed most of your comments, I'll move forward and merge this, feel free to add any additional comment and we can fix on top in follow up PRs

andreaTP added 2 commits October 20, 2026 15:50

Add InterfaceVersions to match semver-compatible interface names

08b143d

Resolve host imports to semver-compatible interface versions

ad22c07

andreaTP mentioned this pull request Oct 20, 2026

Run the Rust corpus programs end to end through WasiPreview2 #72

Open

andreaTP requested review from Phoenixxo and jeremyg484 October 20, 2026 16:05

jeremyg484 approved these changes Oct 20, 2026

View reviewed changes

Phoenixxo reviewed Oct 20, 2026

View reviewed changes

andreaTP added 2 commits October 21, 2026 10:27

Index host interface names by compatible key once per instantiation

3933ee7

Resolve compatible names inside hasImport and getImport and decide th…

67237ef

…e host boundary in one place

andreaTP merged commit d2fd850 into roastedroot:main Oct 21, 2026
3 checks passed

jeremyg484 mentioned this pull request Oct 21, 2026

Implementation of wasi:cli@0.2.12 #70

Merged

Conversation

andreaTP commented Oct 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jeremyg484 left a comment

Choose a reason for hiding this comment

Uh oh!

Phoenixxo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andreaTP commented Oct 21, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

andreaTP commented Oct 20, 2026 •

edited

Loading