wasm: unsupported types abort with internal 'get_wasm_type: unreachable' (ICE) instead of a clean error

[enghitalo]

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 << 1\n}\n' > 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.

[enghitalo]

Did a deeper sweep of the native wasm backend (V 0.5.1 1704098, Linux) and found several more cases in the same family — internal/misleading errors for unsupported constructs instead of a clean, located user error. Recording them here so this stays the umbrella for "wasm backend error quality":

1. Scalar ?T / !T returns → internal ICE. A scalar option/result return (not a MultiReturn) calls get_wasm_type before the existing guards, aborting with get_wasm_type: unreachable type 'int' ast.TypeInfo(ast.UnknownTypeInfo{}) instead of the intended "option/result types are not implemented". Fixed in #27516.

fn f() ?int { return 3 }   // and: fn f() !int { return 3 }

2. Fixed-array .len → internal abort. [N]T{}.len aborts with could not find field 'len' on init (get_field_offset in gen.v). Fixed in #27518 (a fixed array's length is a compile-time constant).

3. Non-string infix (e.g. struct ==) → raw panic with no source position. infix_param_type (vlib/v/gen/wasm/ops.v:~94) does eprintln(*g.table.sym(typ)) + panic('unimplemented infix operation for type'):

struct Point { x int }
fn main() { println(Point{1} == Point{1}) }

main.Point
V panic: unimplemented infix operation for type
... at v_stable_sort: Backtrace      // red-herring symbol (prod-C inlining artifact)

This should be a located v_error like the others.

4. Dynamic-array / map .len → misleading checker error. Because the wasm builtin omits the standard array/map structs, .len resolves as a missing struct field and the checker reports:

error: `[]int` has no property `len`
error: `map[string]int` has no property `len`

which reads like a user typo rather than "this type isn't supported on -b wasm". (Surfaces at vlib/v/checker/checker.v:~3353; root cause is the minimal vlib/builtin/wasm/ builtin set selected in vlib/v/builder/compile.v.)

1–3 are internal-error/panic cases squarely in this issue's scope; 4 is the checker-level cousin (misleading rather than ICE). #27516 and #27518 take care of 1 and 2.