Skip to content

fix(wit-parser): accept a repeated export alias and return decode errors - #2811

Open
imikushin wants to merge 3 commits into
bytecodealliance:mainfrom
imikushin:cursor/fix-shared-implements-instance-type-9ab4
Open

imikushin wants to merge 3 commits into
bytecodealliance:mainfrom
imikushin:cursor/fix-shared-implements-instance-type-9ab4

Conversation

@imikushin

Copy link
Copy Markdown
Contributor

Why

wasm-tools component wit and wit_parser::decoding::decode should handle a valid component that imports the same interface twice under different names via (implements ...), without panicking. Validation already accepts this shape. A repeated export alias that maps to the same WIT type is kept. A conflicting type or function export fails the decode instead of panicking.

Fixes #2806.

What changed

  • register_import keeps an export alias that is already mapped to the same WIT type. A mapping to a different WIT type fails the decode with type export {name} was already mapped to a different type.
  • The interface type-name insert and the function-name insert in register_import use ensure! instead of assert!.
  • A regression test in crates/wit-component/tests/shared_instance_type.rs decodes the reported component and checks the printed WIT.

Scope

Tradeoffs

An error on the repeated alias would stop the panic and still refuse a component WIT can represent. Two distinct instance types of this interface already printed the same WIT. The other asserts in register_import are conflicts, so they return errors.

Blast Radius

Decoding of imported interfaces in register_import. A shared instance type with no resources now decodes to two imports of one interface. A wasm type bound to two different WIT types, or a duplicate type or function name on that interface, fails the decode instead of panicking.

Verification

  • Before the fix, wasm-tools validate --features all exited 0 and wasm-tools component wit panicked at decoding.rs:799.
  • After the alias fix, parse, validate, and component wit exit 0 and print both imports.
  • cargo test -p wit-component@0.263.0 --test shared_instance_type failed on the test commit and passed after the alias fix.
  • cargo test -p wit-component@0.263.0 --test interfaces passed, 42 tests.

Validation accepts a component that imports one interface twice, under
two plain names, through `(implements ...)` on a shared instance type.
Decoding that component panics in `register_import`.
Two imports can share one instance type. The `(type (eq ...))` alias on
that type is allocated once. The first import maps the alias to the WIT
type. The second import maps it to the same type. Keep that mapping.

The assert still rejects a mapping to another WIT type.
Conflicting type and function exports while decoding an imported
interface now fail the decode instead of asserting.
@imikushin
imikushin requested a review from a team as a code owner November 6, 2026 06:29
@imikushin
imikushin requested review from alexcrichton and removed request for a team November 6, 2026 06:29

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

wit-parser panics decoding a valid component with two implements imports sharing an instance type

1 participant