Summary
A user variable named inf is resolved as the zero-arity Inf builtin in expression position. In src/simlin-engine/src/ast/expr1.rs (~line 203) the lowering maps the bare identifier inf to BuiltinFn::Inf ("inf" => check_arity!(Inf, 0)) before checking whether a model variable shadows that name. As a result, any equation referencing a variable named inf reads +infinity instead of the variable's value, silently poisoning downstream results with Inf/NaN.
This bites LTM-synthesized helpers too: an LTM PREVIOUS-helper aux built over a model variable named inf reads +infinity, so link scores through it come out NaN. It was found while building LTM test models -- a flow named inf produced NaN link scores -- but the root cause is not LTM-specific; it affects any model with a variable named inf (and likely the other zero-arity builtin names such as pi, nan, etc.).
Why it matters
This is silent numeric corruption. The model compiles without error, and the user sees Inf/NaN propagating through results with no diagnostic pointing at the shadowed name. The name is unusual, which lowers the practical frequency, but the failure mode (no error, wrong numbers) is severe when it does occur.
Component(s) affected
src/simlin-engine/src/ast/expr1.rs (~line 203, builtin lowering for zero-arity builtins)
- Anything that references such a variable, including LTM-synthesized
PREVIOUS-helper auxes.
Possible approaches
- Only treat
inf / pi / other zero-arity builtins as builtins when no model variable shadows the name (resolve the variable first, fall back to the builtin).
- Or reject such a variable name at parse time with a clear error so the collision is loud rather than silent.
Severity
Minor-to-major -- silent numeric corruption (Inf/NaN), but triggered only by an unusual variable name.
Context
Found while building LTM test models during a 2026-06-02 design review (a flow named inf produced NaN link scores). Not LTM-specific.
Summary
A user variable named
infis resolved as the zero-arityInfbuiltin in expression position. Insrc/simlin-engine/src/ast/expr1.rs(~line 203) the lowering maps the bare identifierinftoBuiltinFn::Inf("inf" => check_arity!(Inf, 0)) before checking whether a model variable shadows that name. As a result, any equation referencing a variable namedinfreads+infinityinstead of the variable's value, silently poisoning downstream results withInf/NaN.This bites LTM-synthesized helpers too: an LTM
PREVIOUS-helper aux built over a model variable namedinfreads+infinity, so link scores through it come outNaN. It was found while building LTM test models -- a flow namedinfproducedNaNlink scores -- but the root cause is not LTM-specific; it affects any model with a variable namedinf(and likely the other zero-arity builtin names such aspi,nan, etc.).Why it matters
This is silent numeric corruption. The model compiles without error, and the user sees
Inf/NaNpropagating through results with no diagnostic pointing at the shadowed name. The name is unusual, which lowers the practical frequency, but the failure mode (no error, wrong numbers) is severe when it does occur.Component(s) affected
src/simlin-engine/src/ast/expr1.rs(~line 203, builtin lowering for zero-arity builtins)PREVIOUS-helper auxes.Possible approaches
inf/pi/ other zero-arity builtins as builtins when no model variable shadows the name (resolve the variable first, fall back to the builtin).Severity
Minor-to-major -- silent numeric corruption (Inf/NaN), but triggered only by an unusual variable name.
Context
Found while building LTM test models during a 2026-06-02 design review (a flow named
infproduced NaN link scores). Not LTM-specific.