fix(interpreter): return runtime errors for division by zero and integer overflow

[gengjiawen]

Problem

The tree-walking interpreter still did raw i64 arithmetic in eval_integer_infix and eval_prefix_minus:

• 1 / 0; → panicked at interpreter/lib.rs:425: attempt to divide by zero — in release builds too (Rust always checks division), killing the REPL/process.
• let m = -9223372036854775807 - 1; m / -1; → panic (divide with overflow), all profiles.
• 9223372036854775807 + 1; → panic in debug builds, silent wrap in release builds — evaluation semantics depended on the build profile.

The bytecode VM was already hardened (compiler/vm.rs uses checked_* and returns classified runtime errors); the interpreter was the un-hardened outlier.

Fix

Use checked_add/sub/mul/div/neg and return EvalError with the exact wording the bytecode VM uses (division by zero, integer overflow in addition/subtraction/multiplication/division/negation), so both engines report these cases identically. Boundary values that fit in i64 (e.g. -9223372036854775807 - 1) still evaluate normally.

Before/after on the REPL:

>> 1 / 0;
thread 'main' panicked at interpreter/lib.rs:425:45: attempt to divide by zero   # before
division by zero                                                                 # after, REPL keeps running

Testing

• New test_integer_arithmetic_errors pins all six error cases; test_integer_arithmetic_boundaries_still_evaluate pins that i64::MIN-adjacent values still work.
• cargo test --workspace: 396 passed, 0 failed. Clippy and cargo fmt --check clean.
• Verified the REPL binary now prints the errors and keeps running.

Affected crates: interpreter only. (The GC VM's wrapping_* add/sub/mul drift vs the compiler VM is a separate known issue, not touched here.)

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
monkey-playground	Ready	Preview	Aug 11, 2026 3:25am