# 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

```sx
#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.