fix(ir): array-dim/count path joins the unified float→int rule — all 5 sites consistent [F0.11]

The compile-time count fold (array dimension / Vector lane / value-param) was
integer-only: it folded a DIRECT integral float literal (`[4.0]`, `[N]` with
`N : f64 : 4.0`) but rejected an INTEGRAL expression built from a non-integral
float-const leaf (`[F + 1.5]` = 4.0, `F : f64 : 2.5`) — and a const folded from
one (`[K]` with `K : s64 : F + 1.5`) — as "must be a compile-time integer
constant". This was the last of issue 0095's five narrowing sites (local /
field / param / const / array-dim) still diverging.

Route the count fold through the SAME compile-time float evaluation the other
four sites use:

- New `program_index.foldCountI64` — the single int-or-integral-float count
  fold: `evalConstIntExpr` first, then (only on failure) `evalConstFloatExpr` +
  `floatToIntExact`. `foldDimU32` (dim/lane/u32 value-param), the non-u32
  value-param gate, and `emitModuleConst`'s integer-const materialization all
  delegate to it, so a const's emitted value and its use as a count come from
  one fold (no parallel integral check, no two-resolver divergence — issue 0083).
- New `DimU32.non_integral_float` variant carries a non-integral float dim to a
  distinct, accurate diagnostic ("array dimension must be an integer, but '2.75'
  is a non-integral float") — the cast-escape advice the binding sites give does
  not apply in a count position, so the dim wording omits it. `reportDimError`,
  the Vector-lane resolver, and the top-level array-alias diagnostic all handle
  the new variant, so the DIRECT and type-ALIAS forms emit the identical message.
- `type_bridge.StatelessInner.lookupFloatName` (via `moduleConstFloat`) is the
  float twin of its `lookupDimName`, so the registration-time alias path folds a
  float-const-leaf dimension to the SAME count as the stateful direct path.

`inline for` range bounds are spec endpoints, not counts (specs.md §2), so they
keep the int-only fold deliberately (no silent-truncation bug there).

Relaxes the F0.4 `examples/1132` wording: a non-integral float const dim now
reports the precise "non-integral float" message (it still errors).

Regression: 0168 (positive — `[F + 1.5]s64`, `[KF]s64`, alias `ArrFE` all fold
to len 4), 1146 (negative — `[F + 0.25]s64` errors), 1132 (precise wording), and
a `foldCountI64`/`foldDimU32` unit test. issues/0095 marked RESOLVED (attempt 4).
specs.md + readme.md state the unified rule across all five sites.
This commit is contained in:
agra
2026-06-05 17:43:45 +03:00
parent b6d66d9c56
commit b73363ca4c
13 changed files with 268 additions and 83 deletions

View File

@@ -735,7 +735,7 @@ pub const Lowering = struct {
const precise: ?program_index_mod.DimU32 = if (cd.value.data == .array_type_expr) blk: {
const dim = type_bridge.foldArrayDim(cd.value.data.array_type_expr.length, &self.module.types, &self.program_index.type_alias_map, &self.program_index.module_const_map);
break :blk switch (dim) {
.too_large, .below_min => dim,
.too_large, .below_min, .non_integral_float => dim,
else => null,
};
} else null;
@@ -4190,11 +4190,16 @@ pub const Lowering = struct {
}
/// Evaluate an `inline for` range bound to a comptime integer. Delegates to
/// the shared `program_index.evalConstIntExpr` — the SAME folder the array
/// dimension / Vector lane / value-param paths use — so a literal, a comptime
/// constant (cursor), a module/generic const (`inline for 0..M`), a
/// `<pack>.len` leaf, and any constant-foldable expression over those
/// (`inline for 0..(M + 1)`) all resolve identically. One folder, one answer.
/// the shared `program_index.evalConstIntExpr` — the SAME integer folder the
/// array dimension / Vector lane / value-param count paths build on — so a
/// literal, a comptime constant (cursor), a module/generic const
/// (`inline for 0..M`), a `<pack>.len` leaf, a DIRECT integral float
/// (`0..-2.0` → -2), and any constant-foldable expression over those
/// (`inline for 0..(M + 1)`) all resolve identically. A range bound is an
/// ENDPOINT, not a count (specs.md §2), so it deliberately does NOT take the
/// `foldCountI64` float-const-leaf fallback the count sites add: it accepts a
/// direct integral float but leaves a float-const-leaf expression to the int
/// folder (negatives are valid here, unlike a count).
fn evalComptimeInt(self: *Lowering, node: *const Node) ?i64 {
return program_index_mod.evalConstIntExpr(node, self);
}
@@ -12278,6 +12283,11 @@ pub const Lowering = struct {
d.addFmt(.err, lane_node.span, "Vector lane count {} does not fit in u32", .{v});
return null;
},
.non_integral_float => |v| {
if (self.diagnostics) |d|
d.addFmt(.err, lane_node.span, "Vector lane count must be an integer, but '{d}' is a non-integral float", .{v});
return null;
},
.not_const, .below_min => {
if (self.diagnostics) |d|
d.addFmt(.err, lane_node.span, "Vector lane count must be a positive compile-time integer constant", .{});
@@ -12314,7 +12324,7 @@ pub const Lowering = struct {
if (std.mem.eql(u8, tn, "u32")) {
switch (program_index_mod.foldDimU32(arg_node, self, 0)) {
.ok => |n| return n,
.not_const => {
.not_const, .non_integral_float => {
self.diagValueParamNotConst(arg_node, param_name);
return null;
},
@@ -12329,9 +12339,16 @@ pub const Lowering = struct {
}
}
}
const v = program_index_mod.evalConstIntExpr(arg_node, self) orelse {
self.diagValueParamNotConst(arg_node, param_name);
return null;
// Non-`u32` integer constraint: fold through the SAME unified count fold
// so an integral float arg (`Box(4.0)`, `Make(F + 1.5, ...)`) binds the
// integer it equals, exactly as the `u32` gate above does; a non-integral
// float / non-const arg is not a valid count.
const v = switch (program_index_mod.foldCountI64(arg_node, self)) {
.int => |iv| iv,
.non_integral, .not_const => {
self.diagValueParamNotConst(arg_node, param_name);
return null;
},
};
if (tn_canon) |tn| {
if (program_index_mod.intTypeRange(tn)) |r| {
@@ -14483,12 +14500,16 @@ pub const Lowering = struct {
// An integer-typed const whose initializer is a compile-time integer —
// an int literal/expression, OR an INTEGRAL float that `typedConstInitFits`
// accepted under the unified narrowing rule — materializes as its folded
// int through the SAME `evalConstIntExpr` the count / array-dim path uses.
// (`K : s64 : 4.0` → 4; `K : s64 : M + 2.0` → 4.) Non-foldable shapes
// fall through to the per-kind emitters below.
// int through the SAME `program_index.foldCountI64` the count / array-dim
// path uses, so the const's emitted VALUE and its use as a COUNT come from
// one fold (`K : s64 : 4.0` → 4; `K : s64 : M + 2.0` → 4; and a float-const-
// leaf `KF : s64 : F + 1.5` → 4, which the int-only folder could not reach).
// A non-integral float never arrives (it was rejected at registration); any
// other non-foldable shape falls through to the per-kind emitters below.
if (self.isIntEx(ci.ty)) {
if (self.evalComptimeInt(ci.value)) |iv| {
return self.builder.constInt(iv, ci.ty);
switch (program_index_mod.foldCountI64(ci.value, self)) {
.int => |iv| return self.builder.constInt(iv, ci.ty),
.non_integral, .not_const => {},
}
}
switch (ci.value.data) {