lab/sx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

37
issues/0095-typed-local-float-int-narrowing.md
View File

@@ -68,6 +68,33 @@
> in `M + 0.5` and a local `F : f64 : 2.5` in `F + 0.25` both still truncate
> identically. Float now matches int exactly at that boundary.
>
> **Completion (F0.11 attempt 4)** — attempts 1–3 unified the four binding sites
> (local / field / param / const) for compile-time float exprs, but the ARRAY-
> DIMENSION / count path still diverged: it folded a DIRECT integral float literal
> (`[4.0]`, `[N]` with `N : f64 : 4.0`) yet rejected an INTEGRAL expression built
> from a non-integral float-const leaf (`[F + 1.5]` = 4.0, or `[K]` with
> `K : s64 : F + 1.5`) as "must be a compile-time integer constant" — because the
> dim fold used the int-only `evalConstIntExpr`, never the float-aware path. Closed
> by routing the count fold through the SAME facility 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` (array dim / Vector lane / u32 value-param) and
> the non-`u32` value-param gate both delegate to it, so no count site disagrees
> on which floats fold (the issue-0083 unify-or-diverge rule extended to floats).
> - A 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") rather than the generic "must be a compile-time
> integer constant" — the cast-escape advice the binding sites give does not apply
> in a dimension 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 (`a : [F + 0.25]s64`) and type-ALIAS
> (`Arr :: [F + 0.25]s64`) forms emit the identical message.
> - `type_bridge.StatelessInner.lookupFloatName` (routed through `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. This 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 tests: `examples/0168-types-integral-float-to-int.sx` (positive —
> local/field/param/const fold, integral int-const-EXPRESSION (`M + 2.0`) AND
> float-const-LEAF (`F + 1.5`, `F : f64 : 2.5`) fold at local/field/param/const,
@@ -77,9 +104,15 @@
> (`F + 0.25`) error at local/param/field), the integral-float const cases in
> `examples/0162-types-typed-module-const-roundtrip.sx`, and the aligned const
> diagnostic in `examples/1143-diagnostics-typed-module-const-mismatch.sx`
> (G / BAD / BAD2 stay errors with the new wording). Unit:
> (G / BAD / BAD2 stay errors with the new wording). The array-dimension site is
> pinned in the same two examples: 0168 adds `[F + 1.5]s64`, `[KF]s64`
> (`KF : s64 : F + 1.5`), and a type-alias `ArrFE :: [F + 1.5]s64` all folding to
> len 4; 1146 adds `[F + 0.25]s64` erroring; `examples/1132` now expects the
> precise non-integral-float dim wording. Unit:
> `program_index.test.zig` "evalConstFloatExpr folds comptime float expressions"
> (covers the float-const leaf: `F` → 2.5, `F + 0.25` → 2.75, `F + 1.5` → 4.0).
> (covers the float-const leaf: `F` → 2.5, `F + 0.25` → 2.75, `F + 1.5` → 4.0) and
> "foldCountI64 / foldDimU32 fold an integral float count, reject a non-integral
> one" (the count fold + the `non_integral_float` / `below_min` distinction).
## Symptom
A typed LOCAL (and likely typed param/field) silently truncates a floating-point