Files
sx/issues/0087-oversized-comptime-int-dimension-panics.md
agra d8076b9333 lang: rename signed integer types sN -> iN
Surface rename of the signed integer family: s1..s64 become i1..i64
(u1..u64, usize, isize unchanged). 'string' keeps the s-prefix arm in
name classification; width parsing moves to the i-prefix arm next to
isize.

Internal TypeId tags follow the surface (.s8/.s16/.s32/.s64 ->
.i8/.i16/.i32/.i64), as do mono-key mangle fragments (ptr_i64,
tu_i64_bool) and all display/diagnostic formatting (i{d}).

Migrated in the same sweep: stdlib + examples + issue repros + FFI C
companions (shared symbol names like ffi_id_i64), expected
stdout/stderr/ir snapshots, specs.md, readme.md, CLAUDE.md/AGENTS.md,
implementation_plan.md, docs/, issue writeups. Vendored stb_image and
historical flow state left untouched.

zig build test: 426/426; examples suite: 595/595.
2026-06-12 09:31:53 +03:00

2.9 KiB

0087 - oversized compile-time integer in type dimension/lane panics

RESOLVED. Root cause: an array dimension / Vector lane folded to a valid i64 (e.g. 5_000_000_000) was then narrowed to u32 with an unchecked @intCast at three sites (Lowering.resolveArrayLen lower.zig:11656, Lowering.resolveVectorLane lower.zig:11836, StatelessInner.resolveArrayLen type_bridge.zig:58), aborting the COMPILER with "integer does not fit in destination type" — the fold was correct, the narrowing was not. Fix: a single range-checked fold-to-u32 gate, program_index.foldDimU32(node, ctx, min), folds via evalConstIntExpr then checks [min, maxInt(u32)] and returns a tagged DimU32 (.ok / .not_const / .below_min / .too_large). Every dim/lane narrowing now routes through it — no call site does a bare @intCast, so an out-of-u32-range dim/lane surfaces a clean diagnostic ("array dimension N does not fit in u32" / "Vector lane count N does not fit in u32") and halts the build (exit 1) instead of panicking. Value-param args stay i64 until used as a dim/lane, where the same gate checks them. Files: src/ir/program_index.zig (DimU32 + foldDimU32), src/ir/lower.zig, src/ir/type_bridge.zig. Regressions: examples/1130-diagnostics-array-dim-oversized-u32.sx (oversized array dim → clean halt) and examples/1503-vectors-oversized-lane-not-u32.sx (oversized Vector lane → clean halt).

Symptom

An oversized compile-time integer used where the compiler expects a u32 array dimension or Vector lane count panics inside the compiler instead of emitting a source diagnostic.

Observed: @intCast panics with "integer does not fit in destination type" in Lowering.resolveArrayLen / Lowering.resolveVectorLane.

Expected: compile halts with a normal diagnostic such as "array dimension does not fit in u32" / "Vector lane count must fit in u32", and no compiler panic.

Reproduction

#import "modules/std.sx";

main :: () {
    a : [5000000000]i64 = ---;
    print("{}\n", a.len);
}

Vector lane sibling:

#import "modules/std.sx";

main :: () {
    v : Vector(5000000000, f32) = .[];
    print("{}\n", v);
}

Investigation prompt

Fix oversized compile-time integer handling for fixed-array dimensions and Vector lane counts. Suspected area: src/ir/lower.zig Lowering.resolveArrayLen and Lowering.resolveVectorLane, plus the stateless adapter in src/ir/type_bridge.zig StatelessInner.resolveArrayLen. These functions fold to i64 through program_index.evalConstIntExpr, then cast to u32 with @intCast; values greater than std.math.maxInt(u32) panic in the compiler. The fix likely needs an explicit range check before every u32 cast, with a diagnostic on the stateful path and null / .unresolved propagation on the stateless path. Verify both repros exit 1 with source diagnostics and no panic, then run zig build && zig build test && bash tests/run_examples.sh.