95adc52609
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.
30 lines
1.3 KiB
Plaintext
30 lines
1.3 KiB
Plaintext
// A raw value binding whose spelling shadows a builtin INTEGER type name
|
|
// (`` `s8 ``) used as an array DIMENSION through one of its fields. Field
|
|
// access on a raw value is an ORDINARY runtime field read, so `` `s8.max `` is
|
|
// a runtime value — NOT the builtin `s8.max` (= 127) and NOT a compile-time
|
|
// constant. An array dimension demands a compile-time integer constant, so the
|
|
// dimension is rejected with the same diagnostic a plainly-named runtime field
|
|
// read (`b.max`) earns — the backtick spelling changes nothing.
|
|
//
|
|
// Sibling (integer) half of the F0.11-7 fix: the compile-time INTEGER evaluator
|
|
// (`evalConstIntExpr`) misclassified a raw value-shadow receiver as the builtin
|
|
// `<IntType>.min`/`.max` accessor, silently folding 127 and fabricating a
|
|
// 127-element array. The `is_raw` guard now defers it to an ordinary field
|
|
// read, so it surfaces as a non-constant dimension instead of a silent wrong
|
|
// length.
|
|
//
|
|
// Negative companion to 0169 (the FLOAT-field narrowing half, exit 0).
|
|
//
|
|
// Regression (issue 0095 / F0.11-7).
|
|
#import "modules/std.sx";
|
|
|
|
DimBox :: struct { max: s64; }
|
|
|
|
main :: () {
|
|
`s8 := DimBox.{ max = 3 };
|
|
// Raw value-shadow field read → a runtime value, not the builtin `s8.max`
|
|
// (127) and not a compile-time constant → rejected as a non-const dim.
|
|
arr : [`s8.max]f32 = ---;
|
|
print("len={}\n", arr.len);
|
|
}
|