b73363ca4c
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.
20 lines
796 B
Plaintext
20 lines
796 B
Plaintext
// A NON-integral float constant (`4.5`) used as an array dimension is a hard
|
|
// error — only an integral float (`4.0`) folds to a count. Clean diagnostic +
|
|
// non-zero exit, NOT a fabricated length.
|
|
//
|
|
// The dimension follows the unified float→int narrowing rule (F0.11 / issue
|
|
// 0095): an integral float folds, a non-integral one is rejected as "not an
|
|
// integer" — the SAME `floatToIntExact` judgement the typed local/field/param/
|
|
// const sites use (the count path is the last of the five sites to unify).
|
|
//
|
|
// Regression (F0.4 attempt 8, Agra ruling): the integral-float rule accepts
|
|
// `4.0` as a dimension but must keep rejecting `4.5` (it is not an integer).
|
|
#import "modules/std.sx";
|
|
|
|
N : f64 : 4.5;
|
|
|
|
main :: () {
|
|
a : [N]s64 = ---;
|
|
print("unreachable: {}\n", a.len);
|
|
}
|