sx/issues/0093-global-raw-value-numeric-limit-shadow.md

RESOLVED (NL.2 attempt 4). Root cause: the issue-0092 fix guarded the numeric-limit intercept against value shadowing using ONLY lexical Scope.lookup. But the ordinary identifier field-access path resolves a value through THREE sources (expr_typer.zig .identifier arm): lexical scope → program global_names → module value constants module_const_map. A backtick raw identifier bound at MODULE scope (`f64 := Box.{…}, a global, or `f64 :: Box.{…}, a module const) is registered in global_names / module_const_map, NOT in Scope, so the scope-only guard missed it and the intercept still folded `f64.epsilon to the numeric limit — the same silent-wrong-value bug as 0092, one source deeper. The module-const variant has the same root cause and is covered by the same fix (no separate issue).

Fix (close ALL THREE value-binding sources in one pass): a single shared helper Lowering.identifierBindsValue(name) returns true when name resolves through scope.lookup OR program_index.global_names OR program_index.module_const_map. Used in BOTH resolvers so they cannot desync (issue-0083 two-resolver class):

• src/ir/lower.zig — lowerNumericLimit: defer to ordinary field lowering (return null) when an .identifier receiver identifierBindsValue.
• src/ir/expr_typer.zig — numeric-limit inference arm: the shadowed check now calls the same helper.

A bare f64.epsilon / i32.max (a .type_expr receiver, never an .identifier) still folds, even when a global or module-const raw value of the same spelling exists — the bare receiver is never value-shadowed. Float-only-on-int and non-numeric-receiver errors are unchanged.

Regression: examples/0161-types-numeric-limit-value-shadow.sx now exercises all three binding kinds — a GLOBAL `f32, a MODULE-CONST `i16, and LOCAL `f64/`i32/`u8 — each reading its field while the bare spelling still folds. Unit test src/ir/expr_typer.test.zig pins the global

• module-const sources. NL.1 (examples/0148) / NL.2 (examples/0159, examples/0160) unregressed.

0093 — numeric-limit intercept hijacks global raw reserved-spelled value receivers

Symptom

Field access on a global raw reserved-spelled value binding is interpreted as a builtin type numeric-limit access instead of an ordinary value field access. Observed: the repro prints 0.000000 2147483647 (f64.epsilon / i32.max). Expected: it prints 12 78 from the Box fields.

Reproduction

#import "modules/std.sx";

Box :: struct { epsilon: i64; max: i64; }

`f64 := Box.{ epsilon = 12, max = 34 };
`i32 := Box.{ epsilon = 56, max = 78 };

main :: () -> i32 {
    print("{} {}\n", `f64.epsilon, `i32.max);
    return 0;
}

Investigation prompt

Investigate issue 0093: the issue-0092 value-binding precedence fix covers lexical locals but misses global raw value bindings. In src/ir/lower.zig, start at Lowering.lowerNumericLimit and the new issue-0092 guard around Scope.lookup. That guard returns null for a shadowing local, but global raw bindings are registered in ProgramIndex.global_names (and module constants in ProgramIndex.module_const_map), not in Scope, so an .identifier receiver whose text is f64 / i32 still folds to a numeric limit before ordinary global field lowering can read the value. Mirror the same rule in src/ir/expr_typer.zig so inferred types match lowering.

Likely fix: for .identifier numeric-limit receivers, prefer any in-scope value binding source over the builtin-type fold: lexical Scope.lookup, global values (program_index.global_names), and module value constants where applicable. Keep .type_expr receivers folding as type receivers, so bare f64.epsilon and i32.max still fold even when a raw global value of the same spelling exists.

Verification: pin the repro above as a regression. It should print 12 78. Also verify the existing numeric-limit examples still pass: examples/0148-types-int-numeric-limits.sx, examples/0159-types-float-numeric-limits.sx, examples/0160-types-float-numeric-limits-errors.sx, and examples/0161-types-numeric-limit-value-shadow.sx.