a491a1bf73
Attempts 1–4 fixed the array-dimension paths but the same length-0 fabrication class survived on every other site that resolves a compile-time integer. Unify them all on the single shared `program_index.evalConstIntExpr` so they cannot diverge: - All three Vector lane resolvers (resolveTypeCallWithBindings, resolveParameterizedWithBindings, resolveArrayLiteralType) and both generic value-param binders (instantiateGenericStruct, instantiateTypeFunction) hand-rolled an `else => 0` switch. A module-const lane `Vector(N, f32)` fabricated a 0-lane `<0 x float>` (LLVM "huge alignment" abort); a value-param `Vec(N, f32)` fabricated a 0 binding / wrong mangled name. They now fold through the shared evaluator and emit a clean diagnostic + `.unresolved` on a non-const operand (resolveVectorLane / resolveValueParamArg) — never 0. - evalComptimeInt (inline-for bounds) delegated to the shared evaluator, so `inline for 0..M` / `0..(M+1)` fold like array dims. The `<pack>.len` leaf moved into the shared folder via a new `ctx.lookupPackLen`. - The unknown-type semantic checker no longer walks a value-param position (`Vector(N, …)` / `Vec(N, …)`) as a type name (was reporting "unknown type 'N'"). - The parameterized-type-arg parser and the function-body lookahead (hasFnBodyAfterArrow) accept a const-EXPRESSION in a value position, so `Vector(M + 1, f32)` and `[M + 1]T` parse as a return type too (the latter a pre-existing array-dim sibling that the same heuristic broke). Regressions: examples/1501 (named-const + const-expr lane, direct + alias, 3/4-lane reads), 1502 (runtime lane clean-halts, exit 1, no LLVM crash), 0207 (Vec(N)/Vec(M+1) == Vec(3) instantiation), 0610 (inline-for const bounds). Shared-evaluator unit test extended with the pack-len arm. zig build && zig build test && bash tests/run_examples.sh: 395 passed, 0 failed.
30 lines
1.3 KiB
Plaintext
30 lines
1.3 KiB
Plaintext
// A generic value parameter (`$K: u32`) bound from a named const or a
|
|
// constant-foldable expression resolves to the SAME monomorphised instantiation
|
|
// as the literal form: `Vec(N, f32)` (N a module const) and `Vec(M + 1, f32)`
|
|
// (a const expression) are both `Vec(3, f32)`. The struct-copy assignment is the
|
|
// proof — it type-checks only because the two spellings name one instantiation.
|
|
//
|
|
// Regression (issue 0083): the value-param binder hand-rolled an `else => 0`
|
|
// switch, so a named-const value arg either fabricated a 0 binding under a wrong
|
|
// mangled name or was rejected outright as "unknown type 'N'". It now folds
|
|
// through the shared const-int evaluator (`program_index.evalConstIntExpr`).
|
|
#import "modules/std.sx";
|
|
|
|
N :: 3;
|
|
M :: 2;
|
|
|
|
Vec :: struct ($K: u32, $T: Type) { data: [K]T; }
|
|
|
|
main :: () {
|
|
a : Vec(N, f32) = ---; // named-const value param
|
|
a.data[0] = 10.0; a.data[1] = 20.0; a.data[2] = 30.0;
|
|
print("named: len={} a0={} a2={}\n", a.data.len, a.data[0], a.data[2]);
|
|
|
|
e : Vec(M + 1, f32) = ---; // const-expr value param (M + 1 == 3)
|
|
e.data[0] = 1.0; e.data[2] = 9.0;
|
|
print("expr: len={} e2={}\n", e.data.len, e.data[2]);
|
|
|
|
b : Vec(3, f32) = a; // same instantiation → struct copy type-checks
|
|
print("copy: len={} b2={}\n", b.data.len, b.data[2]);
|
|
}
|