fix(ir): const evaluators' field-access arm is raw value-shadow aware [F0.11]
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:
@@ -298,9 +298,17 @@ pub fn evalConstIntExpr(node: *const Node, ctx: anytype) ?i64 {
|
||||
.identifier => |id| ctx.lookupDimName(id.name),
|
||||
.type_expr => |te| ctx.lookupDimName(te.name),
|
||||
.field_access => |fa| blk: {
|
||||
// A backtick RAW receiver (`` `s64.max ``, `` `f64.epsilon ``) is an
|
||||
// ordinary field READ on a value whose spelling shadows a builtin
|
||||
// type name, NOT a numeric-limit / pack-arity accessor — so it is
|
||||
// never a compile-time leaf here; its field is a runtime value
|
||||
// (issues 0092/0093, F0.11-7). Only a BARE type/name receiver folds a
|
||||
// `<pack>.len` / `<IntType>.min`/`.max`. Mirrors the same `is_raw`
|
||||
// guard `isFloatValuedExpr` already applies, so the const cluster
|
||||
// (this folder, `evalConstFloatExpr`, `isFloatValuedExpr`) agrees.
|
||||
const obj_name: ?[]const u8 = switch (fa.object.data) {
|
||||
.identifier => |id| id.name,
|
||||
.type_expr => |te| te.name,
|
||||
.identifier => |id| if (id.is_raw) null else id.name,
|
||||
.type_expr => |te| if (te.is_raw) null else te.name,
|
||||
else => null,
|
||||
};
|
||||
if (obj_name) |on| {
|
||||
@@ -397,9 +405,15 @@ pub fn evalConstFloatExpr(node: *const Node, ctx: anytype) ?f64 {
|
||||
// uses) so the two evaluators can't disagree on what `f64.max`
|
||||
// evaluates to. Integer limits and `<pack>.len` are already resolved
|
||||
// by the int delegation above, so only the float-limit case remains.
|
||||
// A backtick RAW receiver (`` `f64.epsilon ``) is an ordinary field
|
||||
// READ on a value that shadows a builtin float type name, NOT the
|
||||
// numeric-limit accessor — its field is a runtime value, never a
|
||||
// compile-time leaf (issues 0092/0093, F0.11-7). Mirrors the `is_raw`
|
||||
// guard `isFloatValuedExpr` already applies; only a BARE type receiver
|
||||
// folds a float limit.
|
||||
const obj_name: ?[]const u8 = switch (fa.object.data) {
|
||||
.identifier => |id| id.name,
|
||||
.type_expr => |te| te.name,
|
||||
.identifier => |id| if (id.is_raw) null else id.name,
|
||||
.type_expr => |te| if (te.is_raw) null else te.name,
|
||||
else => null,
|
||||
};
|
||||
if (obj_name) |on| {
|
||||
|
||||
Reference in New Issue
Block a user