globalInitValue's issue-0071 .identifier arm closed the bare-identifier hole, but .field_access (and every other non-literal expression shape) still fell through to `else => null`, so a global like `g : s32 = K.x;` was emitted with no payload and silently zero-initialized (g=0). Make the `else` emit a diagnostic — "global '<name>' must be initialized by a compile-time constant" — instead of a null payload, so no unsupported shape can silently zero. Two arms added alongside: - `.null_literal => .null_val`: a `*void = null` global was previously a no-payload zero-init; this preserves the exact LLVMConstNull emission (fixes 3 ffi examples that regressed on the first cut). - explicit `.enum_literal => null` carve-out: the stdlib's `OS : OperatingSystem = .unknown;` zero-init is load-bearing for compile-time `inline if OS == .X`; documented, not folded into a silent fallthrough. Field-access constant *evaluation* (materializing K.x -> 9) is intentionally not implemented: a typed struct const like K is not registered in module_const_map, so it would require new plumbing whose writes are read at runtime — out of scope. The diagnostic is the issue-sanctioned outcome. Regression: examples/1118-diagnostics-global-non-const-initializer-rejected.sx (exit 1). Gate: zig build, zig build test, run_examples.sh -> 356/0.
2 lines
2 B
Plaintext
2 lines
2 B
Plaintext
1
|