Description

Four builtin functions accept arguments of the wrong type without the typechecker catching it. The typechecker validates argument count for these builtins but not argument types, so invalid calls pass through and crash during C compilation.

All four are the same root cause: missing type checks in the typechecker's builtin handling.

Reproduction

1. range() with string arguments (expects int):

do main() {
    for i in range("a", "z") {
        println(i)
    }
}

C error: initializing 'int64_t' with an expression of incompatible type 'EzString'

2. assert() with string condition (expects bool, string):

do main() {
    assert("hello", "message")
}

C error: passing 'EzString' to parameter of incompatible type 'bool'

3. exit() with string argument (expects int):

do main() {
    exit("goodbye")
}

C error: passing 'EzString' to parameter of incompatible type 'int64_t'

4. panic() with int argument (expects string):

do main() {
    panic(42)
}

C error: passing 'int' to parameter of incompatible type 'EzString'

Root Cause

The typechecker handles builtins in the call expression resolver but only validates argument count, not argument types. For regular user-defined functions, argument types are checked against the function signature. Builtins don't have formal signatures registered in the typechecker, so their argument types are never validated.

Fix

In the typechecker's builtin call handling (where range, assert, exit, panic are resolved), add type checks for each:

Emit the standard E3001 type mismatch error (or a new builtin-specific code) when the argument type doesn't match.

Notes

Other builtins may have the same gap. After fixing these four, it would be worth auditing the remaining builtins (len, copy, cast, addr, ref, new, sleep_s, sleep_ms, sleep_ns, c_string, error) to confirm they all validate argument types. Some of these already do (e.g., len checks for E7015, new checks for E3041), but a full audit would catch any remaining gaps.