efc09699e8
Two remaining siblings in F0.4's comptime-int path.
1. Type-returning function with a value param used as a TYPE annotation
(`b : Make(N, s64)` where `Make :: ($K: u32, $T: Type) -> Type`):
- `isValueParamPosition` (semantic_diagnostics) now also skips a value
param of a `fn_ast_map` type-returning function, so `N` is not walked
as the type name "N" ("unknown type 'N'").
- `resolveParameterizedWithBindings` routes a type-returning-function
name to `instantiateTypeFunction` (the `.call` path already did).
- `instantiateTypeFunction` resolves a general return-type expression
(`return [K]T`) with bindings active — not just struct/union returns.
`Make(N, s64)`, `Make(M + 1, s64)`, `Make(3, s64)` all resolve to one
`[3]s64`.
2. Oversized dim/lane fold panicked the compiler (0087): an array dim /
Vector lane folded to a valid i64 (5e9) then narrowed to u32 with an
unchecked `@intCast`. New single gate `program_index.foldDimU32` folds
via `evalConstIntExpr` then range-checks `[min, maxInt(u32)]`; the three
narrowing sites (resolveArrayLen stateful + stateless, resolveVectorLane)
all route through it and emit a clean diagnostic + halt instead of
panicking. Value-param args stay i64 until used as a dim/lane, where the
same gate checks them.
Regressions: examples/0208 (value-param type function), examples/1130
(oversized array dim clean halt), examples/1503 (oversized Vector lane
clean halt). Marks issue 0087 RESOLVED.
Gate: zig build, zig build test, bash tests/run_examples.sh — 398 passed,
0 failed, 0 timed out.
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 tou32with an unchecked@intCastat three sites (Lowering.resolveArrayLenlower.zig:11656,Lowering.resolveVectorLanelower.zig:11836,StatelessInner.resolveArrayLentype_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 viaevalConstIntExprthen checks[min, maxInt(u32)]and returns a taggedDimU32(.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 stayi64until 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) andexamples/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]s64 = ---;
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.