Files
sx/examples/expected
agra 6478ccbe3c fix(lang): numeric-limit shadow guard covers all 3 value sources [NL.2]
The issue-0092 fix guarded the numeric-limit accessor intercept against
raw value shadowing using only lexical Scope.lookup. The ordinary
identifier field-access path resolves a value through THREE sources
(scope / program_index.global_names / program_index.module_const_map),
so a backtick raw identifier bound at module scope — a global
`` `f64 := Box.{…} `` or a module constant `` `f64 :: Box.{…} `` — still
folded `` `f64.epsilon `` to the numeric limit instead of reading the
value's field (issue 0093, plus the module-const variant: same root
cause, same fix).

Fix: a single shared helper Lowering.identifierBindsValue(name) that
returns true when the name resolves through scope OR global_names OR
module_const_map. Used in BOTH lowerNumericLimit (lower.zig) and the
numeric-limit inference arm (expr_typer.zig) so the two resolvers can't
desync (issue-0083 class). A bare `f64.epsilon` / `s32.max` (a
.type_expr receiver) still folds even when a raw value of the same
spelling is bound — the bare receiver is never value-shadowed.

- examples/0161: extended to exercise all three binding kinds — a
  GLOBAL `` `f32 ``, a MODULE-CONST `` `s16 ``, and LOCAL
  `` `f64 ``/`` `s32 ``/`` `u8 `` — each reading its field while the
  bare spelling still folds.
- src/ir/expr_typer.test.zig: unit test pinning the global +
  module-const sources of the shared guard.
- issues/0093: RESOLVED banner (3-source root cause + fix, module-const
  variant folded in).
- specs.md / readme.md: numeric-limit shadow note now source-agnostic
  (local / global / module-const).
2026-06-05 00:21:32 +03:00
..