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

fix(ir): const evaluators' field-access arm is raw value-shadow aware [F0.11]

Browse Source 
A backtick raw value-shadow receiver (`` `f64 := … `` then `` `f64.epsilon ``,
`` `s8.max ``) was misclassified as the builtin numeric-limit accessor by the
shared compile-time evaluators. The sibling `isFloatValuedExpr` already guards
this with an `is_raw` check, but `evalConstFloatExpr` / `evalConstIntExpr` did
not — so once a raw value-shadow's field read flowed into the unified float→int
narrowing rule or an array-dim count, the float folder returned the BUILTIN
`f64.epsilon` (2.22e-16) and wrongly errored, and the integer folder turned
`` `s8.max `` into the builtin `127` (a fabricated 127-element array).

Both evaluators' field-access arms now mirror `isFloatValuedExpr`'s `is_raw`
guard: a raw receiver yields `obj_name = null`, so it is never a
numeric-limit/pack leaf and falls through to the ordinary runtime field read. A
raw value-shadow is a mutable-local field (an observable later reassignment),
so it is genuinely runtime and must not be const-folded — it now behaves exactly
like a plainly-named field read: `` `f64.epsilon `` narrowing into `s64`
truncates its field value (11.5 → 11, identical to `b.epsilon`), and `` `s8.max ``
as an array dimension is rejected as a non-constant count (identical to `b.max`).
The bare builtin path is unchanged.

Regression (issue 0095 / F0.11-7):
- examples/0169-types-value-shadow-field-narrowing.sx (positive — raw float-field
  read narrows/truncates, mutation proves runtime, bare limit still folds)
- examples/1148-diagnostics-value-shadow-field-dim-not-const.sx (negative — raw
  int-field dim rejected as non-const)
- program_index.test.zig "a backtick raw-shadow receiver is a field read, not a
  numeric-limit fold (F0.11-7)"

specs.md + readme.md note the value-shadow rule extends into the narrowing/count
contexts.
This commit is contained in:
agra
2026-06-05 20:02:11 +03:00
parent e442cdf5e7
commit 95adc52609
13 changed files with 194 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -165,6 +165,33 @@
> added to `examples/0168` (`6.0 / 2.0` local/field, `12.0 / 4.0` const, `[6.0 /
> 2.0]` dim, `xx (5.0 / 2.0)` → 2), and unit
> `program_index.test.zig` "the int folder refuses a FLOAT division".
>
> **Completion (F0.11 attempt 7)** — one structural hole survived in the
> field-access arm of the SHARED const evaluators: a backtick raw value-shadow
> receiver (`` `f64 := FBox.{ epsilon = … } `` then `` `f64.epsilon ``) was
> misclassified as the builtin numeric-limit accessor. The sibling
> `isFloatValuedExpr` already guards this with an `is_raw` check, but
> `evalConstFloatExpr` / `evalConstIntExpr` did NOT — so once the read flowed into
> an integer binding, the float folder returned the BUILTIN `f64.epsilon`
> (2.22e-16) and the rule wrongly errored ("narrow non-integral float
> '0.0000…0002220446049250313'"), and the integer folder turned `` `s8.max `` as an
> array dimension into the builtin `127` (a fabricated 127-element array) instead
> of an ordinary runtime field read. Closed at the single root: both evaluators'
> field-access arms now mirror `isFloatValuedExpr`'s `is_raw` guard — a raw
> receiver yields `obj_name = null`, so it is never a numeric-limit/pack leaf and
> falls through to the ordinary runtime field read. A raw value-shadow is a
> mutable-local field (a subsequent `` `f64.epsilon = 4.0 `` is observable), so it
> is genuinely runtime and must not be const-folded: it now behaves EXACTLY like a
> plainly-named field read — `` `f64.epsilon `` narrowing into `s64` truncates to
> its field value (`11.5` → `11`, identical to `b.epsilon`, NOT a non-integral
> error on the builtin limit), and `` `s8.max `` as an array dimension is rejected
> as a non-constant count (identical to `b.max`). The bare builtin path is
> unchanged (`f64.epsilon`, `s8.max`, `[u8.max]` still fold). Regression:
> `examples/0169-types-value-shadow-field-narrowing.sx` (positive — raw float-field
> read narrows/truncates, mutation proves runtime, bare limit still folds),
> `examples/1148-diagnostics-value-shadow-field-dim-not-const.sx` (negative — raw
> int-field dim rejected as non-const), and unit `program_index.test.zig` "a
> backtick raw-shadow receiver is a field read, not a numeric-limit fold (F0.11-7)".
## Symptom
A typed LOCAL (and likely typed param/field) silently truncates a floating-point