Better error message for panic on "failed to find alias" during composition
alexcrichton opened this issue · 3 comments
Given this input as root.wat
:
(component
(import (interface "foo:bar/a") (instance $types
(type $t u32)
(export "t" (type (eq $t)))
))
(alias export $types "t" (type $t'))
(import (interface "foo:bar/b") (instance
(export $t "t" (type (eq $t')))
(export "f" (func (result $t)))
))
(import (interface "foo:bar/c") (instance
(export $t "t" (type (eq $t')))
(export "f" (func (result $t)))
))
)
and this input as dep.wat
:
(component
(type $t u32)
(instance $types (export (interface "foo:bar/a"))
(export "t" (type $t))
)
(alias export $types "t" (type $t'))
(core module $m
(func (export "f") (result i32) unreachable)
)
(core instance $i (instantiate $m))
(func $f (result $t) (canon lift (core func $i "f")))
(instance (export (interface "foo:bar/b"))
(export "t" (type $t'))
(export "f" (func $f))
)
)
then the panic is with:
$ wasm-tools compose root.wat -d dep.wat -o foo.wasm
[2023-07-26T20:54:37Z WARN ] instance `foo:bar/c` will be imported because a dependency named `foo:bar/c` could not be found
thread 'main' panicked at 'failed to find alias of TypeId { index: 0, type_size: 1, unique_id: 1 }', /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasm-compose-0.4.0/src/encoding.rs:660:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
The problem here is that despite A/B being virtualized the final component needs to import C which depends on A, which means that at least the type information from A needs to be imported. Currently though wasm-compose
deduces that A/B are provided by the component instantiation, so only C is imported. This means that during the import of C it asserts that its type information was already imported, which isn't true in this case, thus the panic.
Fixing this will require updates to the dependency graph in wasm-compose
and probably the encoding phase too because only the types from A need to be imported to import C.
This also has first become evident after my refactoring in #1141
I've renamed the title of this issue to be "better error message", as the implementation seems correct, but having debugging information available as to what subsystem needs to be included would be very helpful to be able to debug this in wasi virt workflows.
Note also that wasm-compose
does provide warnings for all unimplemented interfaces, so at least one of these can be known to always be the cause.