vlang

/

v Public
0 commits 39 issues 0 pull requests 0 contributors Discussions Projects CI

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.