hakorune/CLAUDE_WASM_TASK.md

Title: WASM Backend v2 (Phase 12) – Minimal Handoff

Goal

• Implement a new src/backend/wasm_v2/ backend that aligns with the unified vtable/slot dispatch model, without touching MIR-level semantics.

Scope

• Allowed:
  • src/backend/wasm_v2/* (mod.rs, unified_dispatch.rs, vtable_codegen.rs)
  • src/backend/wasm/* read-only for reference
  • projects/nyash-wasm/* (demo HTML/JS harness)
  • Documentation under docs/backend/wasm/*.md
• Avoid (to keep merge easy):
  • MIR layer (no plugin-name hardcoding)
  • src/runtime/* core (HostHandle/host_api/extern are assumed stable)
  • JIT/VM files unless behind feature/cfg guards

Design Constraints

• ExternCall and BoxCall remain separate at the MIR/semantics level.
• At lower layers, converge onto a unified host-call shim when needed (same C symbols as VM/JIT).
• Console/print: use ExternCall(env.console.log); do not move to BoxCall.
• vtable/slots must align with src/runtime/type_registry.rs (see Array/Map/String slots).

Targets & Flags

• Target: wasm32-unknown-unknown
• Feature: --features wasm-backend
• Use #[cfg(feature = "wasm-backend")] and/or #[cfg(target_arch = "wasm32")] to isolate new code.

Acceptance (Minimal)

• Build succeeds for non-wasm targets (no regressions).
• wasm_v2 compiles behind --features wasm-backend (even as stubs).
• A demo harness can call env.console.log from WASM and produce a message.
• (Nice to have) Array/Map len/size/has/get stubs go through unified dispatch.

Next Steps (Optional)

• Implement unified dispatch bridge to JS host for env.console and basic collections.
• Add a minimal test or demo comparing VM vs WASM return values for a simple program.