sx/issues/0113-negative-literal-global-initializer-rejected.md

RESOLVED — 0113: negative-literal global initializer rejected as "not a compile-time constant"

Root cause: globalInitValue (src/ir/lower/decl.zig) had no .unary_op arm, so a negated literal fell into the catch-all "must be initialized by a compile-time constant" — even though constExprValue already folds negate(int/float literal) for the module-const identifier route.

Fix: a .unary_op arm routes the initializer through constExprValue; the folded value follows the direct-literal rules — checkIntLiteralFits on ints (g : i8 = -300; gets the range diagnostic, not "non-constant"), and a negated float at an integer global narrows only when integral (g : i64 = -4.0; → -4; -4.5 errors). Binary-op initializers (g : i32 = 2 + 3;) remain unsupported and keep the specific "must be initialized by a compile-time constant" diagnostic — const-expr folding for those is a separate feature if ever wanted.

Regression test: examples/0175-types-negative-literal-global.sx (prints -1 -4 -128; failed "non-constant" pre-fix).

---

0113 — negative-literal global initializer rejected as "not a compile-time constant"

Symptom. A top-level global initialized with a negated literal fails to compile: g : i64 = -1; errors global 'g' must be initialized by a compile-time constant. Expected: a negated literal is a compile-time constant; the global serializes to -1. Positive literals work (g : i64 = 1;). Locals are unaffected (x : i64 = -1; inside a function is fine — lowerExpr folds the negate).

Reproduction

#import "modules/std.sx";

g : i64 = -1;

main :: () {
    print("{}\n", g);
}

• Observed: error: global 'g' must be initialized by a compile-time constant at the initializer.
• Expected: compiles; prints -1.

Repro co-located: issues/0113-negative-literal-global-initializer-rejected.sx.

Root cause (suspected area)

src/ir/lower/decl.zig globalInitValue (~973): the initializer switch has arms for .int_literal / .float_literal / .bool_literal / etc., but a negated literal is a .unary_op node, which falls into the catch-all else => "must be initialized by a compile-time constant". The identifier arm already routes module-const values through constExprValue (~1013) — the direct .unary_op / .binary_op initializer shapes never get that chance.

Investigation prompt (paste into a fresh session)

Fix issue 0113: g : i64 = -1; (and const-expression initializers like g : i64 = 2 + 3;) are rejected as non-constant globals. In src/ir/lower/decl.zig globalInitValue, route .unary_op and .binary_op initializers through the same const-expression evaluation the .identifier arm uses (constExprValue, or the program_index.evalConstFloatExpr-family used by typedConstInitFits ~878) before falling into the catch-all diagnostic. Apply the int-literal fits-check (checkIntLiteralFits) to the folded value against the global's type — g : i8 = -300; must produce the range diagnostic, not a wrap and not "non-constant". Negative bounds in typedConstInitFits already admit unary_op shapes; keep both checks consistent.

Verify: the repro prints -1; g2 : i8 = -300; errors with the range message; g3 : i32 = 2 + 3; initializes to 5 (or, if expression globals are deliberately unsupported, keeps a SPECIFIC diagnostic saying so). zig build && zig build test && bash tests/run_examples.sh. Promote the repro per the resolution flow.