wasm: unsupported types abort with internal 'get_wasm_type: unreachable' (ICE) instead of a clean error #9
Describe the bug
When a program uses a type the -b wasm backend doesn't support yet — dynamic
arrays ([]T), map, closures, sum types, generics, interfaces — the compiler
aborts with an internal error that dumps raw ast.TypeInfo and carries no
source position:
wasm error: get_wasm_type: unreachable type 'map[string]int' ast.TypeInfo(ast.Map{ … })
This is an internal compiler error (the unreachable fallback in
get_wasm_type), not a user-facing diagnostic. A clean message already exists
for one case — vlib/v/gen/wasm/gen.v:943: 'wasm backend does not support dynamic arrays' — but it is not reached: get_wasm_type panics first, even
for the dynamic-array append case it was meant to cover.
This issue is not a request to implement these features — only that unsupported constructs produce a graceful, located error instead of an ICE, so users get actionable feedback.
Reproduction Steps
# (a) map
printf 'fn f() int {\n\tmut m := map[string]int{}\n\tm["a"] = 1\n\treturn m["a"]\n}\nfn main() { println(f().str()) }\n' > a.v
v -b wasm -o a.wasm a.v
# (b) returning a dynamic array
printf 'fn f() []int { return [1, 2, 3] }\nfn main() { _ := f() }\n' > b.v
v -b wasm -o b.wasm b.v
# (c) dynamic-array append — even this hits the ICE, not the dedicated
# "wasm backend does not support dynamic arrays" message at gen.v:943
printf 'fn main() {\n\tmut a := []int{}\n\ta < c.v
v -b wasm -o c.wasm c.v
The same get_wasm_type: unreachable abort also occurs for closures, sum types,
generics, and interfaces.
Expected Behavior
A clean, located compiler error, e.g.:
b.v:1:14: error: the wasm backend does not support the type `[]int` yet
(like the existing gen.v:943 message), instead of an internal panic.
Current Behavior
wasm error: get_wasm_type: unreachable type 'map[string]int' ast.TypeInfo(ast.Map{
key_type: ast.Type(0x15 = 21)
value_type: ast.Type(0x8 = 8)
name_pos: token.Pos{ len: 0 line_nr: 0 pos: 0 col: 0 …
wasm error: get_wasm_type: unreachable type '[]int' ast.TypeInfo(ast.Array{
nr_dims: 1
elem_type: ast.Type(0x8 = 8)
})
No source location; raw AST dumped to the user.
Possible Solution
In get_wasm_type (vlib/v/gen/wasm/), replace the unreachable fallback for
unsupported type kinds with a g.w_error(...) that carries the node's position
and a human-readable type name — generalizing the existing
'wasm backend does not support dynamic arrays' message so it covers maps,
closures, sum types, generics, and interfaces, and so it is emitted before the
unreachable is hit.
Additional Information/Context
Found while mapping which V constructs the native -b wasm backend accepts (for
a browser CSR project). The contrast: int/float math, println, fixed arrays,
match, for x in a..b, string concatenation, and named structs all compile;
the types above all hit this same get_wasm_type: unreachable path.
V version
V 0.5.1 130caaf — master HEAD, 0.5.1-1901-g130caaf0, 0 commits behind
origin/master (ran the equivalent of v up before reporting).
Environment details (OS name and version, etc.)
V full version V 0.5.1 7bf483e27d402b5205164747a22c6e37ea1d3c18.130caaf
OS linux, Ubuntu 24.04 LTS
Processor 16 cpus, 64bit, little endian, AMD Ryzen 7 5800H
V executable /home/hitalo/v/v
V git status 0.5.1-1901-g130caaf0
cc version cc (GCC) 14.2.0
clang version Ubuntu clang version 18.1.3
tcc version tcc version 0.9.28rc 2025-02-13 HEAD@f8bd136d (x86_64 Linux)
glibc version ldd (Ubuntu GLIBC 2.39-0ubuntu8.7) 2.39
[!NOTE] You can use the 👍 reaction to increase the issue's priority for developers.
Please note that only the 👍 reaction to the issue itself counts as a vote. Other reactions and those to comments will not be taken into account.