wasm: -os browser panics 'called function eprintln does not exist' for any program (even empty main)

[enghitalo]

Describe the bug

Compiling any program with the native WebAssembly backend for the browser
target (-b wasm -os browser) aborts the compiler with:

V panic: called function eprintln does not exist

It happens even for an empty pub fn main() {}, so the -os browser target is
currently unusable. The bundled official example
examples/wasm/change_color_by_id/change_color_by_id.wasm.v — whose README
documents v -b wasm -os browser … — also no longer compiles for the same
reason.

The default WASI target (v -b wasm, no -os browser) compiles the same
trivial programs fine, so the regression is specific to -os browser.

Reproduction Steps

# minimal — an empty main is enough to trigger it
echo 'pub fn main() {}' > m.v
v -b wasm -os browser -o m.wasm m.v

# the bundled official example fails the same way
v -b wasm -os browser examples/wasm/change_color_by_id/change_color_by_id.wasm.v

Expected Behavior

A valid reactor/browser wasm module is produced (as the
examples/wasm/change_color_by_id/README.md instructions imply), with no
compiler panic.

Current Behavior

The compiler panics while emitting the module. Full output for the empty-main
case:

V panic: called function eprintln does not exist
 v hash: 130caaf
    pid: 0x422ba
    tid: 0x422ba
/tmp/v_1000/wasm_builder.01KV1MP15NH47W0MGPQ2VKQ0YJ.tmp.c:1407: at v_stable_sort: Backtrace
/tmp/v_1000/wasm_builder.01KV1MP15NH47W0MGPQ2VKQ0YJ.tmp.c:1407: by v_stable_sort
/tmp/v_1000/wasm_builder.01KV1MP15NH47W0MGPQ2VKQ0YJ.tmp.c:1407: by v_stable_sort
   … (v_stable_sort repeated) …
0x76a8b522a1ca: by ???
0x76a8b522a28b: by ???
0x006055c5: by ???

(-b wasm without -os browser builds the same m.v without error.)

Possible Solution

The wasm builder references an eprintln runtime/host function that is not
registered for the -os browser target (the WASI target appears to register
or route it, the browser target does not), so a later pass — the backtrace
points at v_stable_sort, i.e. while sorting/finalizing the function list
during module emission — looks it up and aborts. Registering the eprintln
builtin (or routing it the same way the WASI target does) for -os browser
should resolve it.

Additional Information/Context

Found while evaluating the three V→WASM routes (native -b wasm, v -cc clang,
pure clang) for a browser client-side-rendering project. This bug rules out the
native -os browser route entirely on current master.

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 home dir           OK, value: /home/hitalo/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.