d8076b9333
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.
65 lines
2.9 KiB
Markdown
65 lines
2.9 KiB
Markdown
# 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
|
|
```sx
|
|
#import "modules/std.sx";
|
|
|
|
main :: () {
|
|
a : [5000000000]i64 = ---;
|
|
print("{}\n", a.len);
|
|
}
|
|
```
|
|
|
|
Vector lane sibling:
|
|
|
|
```sx
|
|
#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`.
|