feat: []Type{elem, ...} composite-literal sugar for arrays; fix named-array-value type checking

Go-style typed array literal syntax, e.g. `xs := []int{1, 2, 3}`.
Desugars to exactly the same construction `var xs []int = [1, 2, 3]`
already compiles to (an anonymous array named_type built once, its
object pushed as a constant, the plain array value passed to it as a
single-arg call) -- reusing that machinery rather than a second
implementation of element-type checking. Supports primitive, struct,
named-type, empty, and nested ([][]int{...}) element types.

Disambiguating this from a plain array literal or an empty [] is
genuinely ambiguous by token lookahead alone: Gengo is newline-
insensitive, so `xs := []` immediately followed by an unrelated new
statement (`func foo() {...}`, `std.io.println(...)`, another `[...]`)
is completely ordinary code that happens to start with a type-spec-like
token. Resolved with real speculative parsing + rollback (save the 4
parser-position fields, attempt to parse a type spec followed by `{`,
restore and fall back to the plain literal on failure) rather than
token-type heuristics.

Two more pre-existing bugs found and fixed along the way (reproduced
with the equivalent `var` syntax too, so not introduced by this sugar):

- vm_types.zig matchesTypeAlt's .array/.map cases never unwrapped a
  .named_value before checking isArrayObject/isMapObject -- passing an
  already-[]T-typed value to a []T-typed function parameter always
  failed with a confusingly identical-looking "expected []T, got []T"
  (both sides render the same runtime type name; the check just never
  looked inside the wrapper constructNamedType's .array_t/.map_t cases
  always produce). This is also why [][]int{...} previously failed:
  each inner element is itself a named-array-typed value.

- The disambiguation logic's first draft (inline in parsePrecedence's
  switch) increased that recursive function's per-call stack frame size
  in an unoptimized/Debug build enough to trip a pre-existing
  "expression too deep" stack-overflow guard test before its own
  software depth counter could fire. Fixed by extracting the whole
  disambiguation into its own function so those locals don't live in
  the recursive function's frame.

Verified clean under standard, -Dpreset=stress, and -Dgc_stress=true.

Author: ganehag

CHANGELOG.md

@@ -4,6 +4,46 @@ This changelog tracks notable language/runtime changes by implementation date.
 
 ## 2026-08-20
 
+### Language — `[]Type{elem, ...}` typed composite-literal sugar for arrays
+
+Go-style typed array literal syntax, e.g. `xs := []int{1, 2, 3}`. Desugars
+to exactly the same construction `var xs []int = [1, 2, 3]` already
+compiled to (an anonymous array named_type built once, its object pushed
+as a constant, the plain array value passed to it as a single-arg call) —
+reusing that machinery rather than a second implementation of element-type
+checking. Supports primitive, struct, named-type, empty, and nested
+(`[][]int{...}`) element types.
+
+Disambiguating this from a plain `[elem, ...]` array literal or an empty
+`[]` is genuinely ambiguous by simple token lookahead: Gengo is newline-
+insensitive, so `xs := []` immediately followed by an unrelated new
+statement (`func foo() {...}`, `std.io.println(...)`, another `[...]`)
+is completely ordinary code that happens to start with a type-spec-like
+token. Resolved with real speculative parsing + rollback (save the 4
+parser-position fields, attempt to parse a type spec followed by `{`,
+restore and fall back to the plain literal if that fails) rather than
+token-type heuristics, which correctly handles every case rather than
+just the common ones.
+
+Two more bugs found and fixed along the way (both pre-existing, not
+introduced by this sugar — reproduced with the equivalent `var` syntax
+too):
+- `matchesTypeAlt`'s `.array`/`.map` cases never unwrapped a `.named_value`
+  before checking `isArrayObject`/`isMapObject` — passing an already-`[]T`-
+  typed value to a `[]T`-typed function parameter always failed with a
+  confusingly identical-looking "expected []T, got []T" (both sides render
+  the same runtime type name; the check just never looked inside the
+  wrapper `constructNamedType`'s `.array_t`/`.map_t` cases always produce).
+  This is also why `[][]int{...}` (or `var [][]int = [...]`) previously
+  failed: each inner element is itself a named-array-typed value.
+- The disambiguation logic's first draft (token-type lookahead) increased
+  `parsePrecedence`'s per-call stack frame size (4 new locals, unconditionally
+  present regardless of which switch arm executes, in an unoptimized/Debug
+  build) enough to trip a pre-existing "expression too deep" stack-overflow
+  guard test before its own software depth counter could fire. Fixed by
+  extracting the whole disambiguation into its own function so those locals
+  don't live in the recursive function's frame.
+
 ### Fix — cap:net IPv6 CIDR policy rules crashed (or hit UB in release builds) for virtually every real prefix length
 
 A coverage audit found `net_state.zig`'s `ipv6InCidr` had zero test

docs/language.md

@@ -595,6 +595,16 @@ nums := [1, 2, 3]
 std.io.println(nums[0])
 ```
 
+An array literal can also be prefixed with an explicit element type — Go-
+style composite-literal syntax — equivalent to (and desugars to exactly the
+same construction as) `var xs []Type = [elem, ...]`:
+
+```gengo
+xs := []int{1, 2, 3}
+pts := []Point{Point{x: 1, y: 2}, Point{x: 3, y: 4}}
+empty := []int{}
+```
+
 Maps:
 
 ```gengo

src/compiler_test.zig

@@ -6649,11 +6649,58 @@ test "compiler: int_div raises RangeError (not a silently wrong answer) for i64:
     try std.testing.expectError(error.RangeError, rt.callGlobal("g", &.{ .{ .int = std.math.minInt(i64) }, .{ .int = -1 } }));
 }
 
+// A copy-paste-divergence audit found .int_div's OTHER path -- reached when
+// either operand is a named-type-wrapped int, via numericBinaryOp/
+// pushNumericResultWithCarrier rather than the plain int/int fast path
+// above -- had silently reintroduced the exact bug the fast path was
+// already fixed for: it returned minInt(i64) unmodified instead of raising
+// RangeError.
+test "compiler: int_div's named-type carrier path also raises RangeError for i64::MIN div -1" {
+    var rt = try setup();
+    defer rt.deinit();
+    try runSrc(&rt,
+        \\type Big int
+        \\func g() int { return int(Big(-9223372036854775808) div Big(-1)) }
+    );
+    try std.testing.expectError(error.RangeError, rt.callGlobal("g", &.{}));
+}
+
+// The same copy-paste-divergence audit found .mod's plain int/int path
+// (unlike its two siblings .int_div and .rem, just above) never checked
+// for this case at all -- @mod(minInt(i64), -1) traps/UB's on the same 2^63
+// overflow, since floored and truncating division coincide when dividing
+// by exactly -1. x mod 1 is always mathematically 0.
+test "compiler: mod does not trap/overflow for i64::MIN mod -1" {
+    var rt = try setup();
+    defer rt.deinit();
+    try runSrc(&rt,
+        \\func g(a int, b int) int { return a mod b }
+    );
+    const result = try rt.callGlobal("g", &.{ .{ .int = std.math.minInt(i64) }, .{ .int = -1 } });
+    try std.testing.expectEqual(@as(i64, 0), result.int);
+}
+
 // std.json.stringify used to serialize any bigint as `null` (falling through
 // the object-tag switch's generic else branch), silently discarding the
 // value entirely. std.conv.to_int/to_float rejected bigint with TypeError
 // even though the direct-dispatched `int(...)`/`float(...)` builtins already
 // supported it — an inconsistency between two paths meant to be equivalent.
+// A capability-module audit found argon2id validated only t/m/p's LOWER
+// bounds (unlike bcryptHash's cost, which is bounded both ways) before
+// @intCast-ing them into std.crypto.pwhash.argon2.Params' u32/u32/u24
+// fields -- an out-of-range value (e.g. m between u32::max and i64::max)
+// panicked that cast immediately, a crash trivially reachable from Gengo
+// source with no wire format or policy misconfiguration needed.
+test "compiler: std.crypto.argon2id rejects an out-of-range m instead of panicking the @intCast" {
+    var rt = try setup();
+    defer rt.deinit();
+    try runSrc(&rt,
+        \\std := import("std")
+        \\func g() string { return std.crypto.argon2id("password", "somesalt1", 1, 999999999999, 1, 32) }
+    );
+    try std.testing.expectError(error.ValueError, rt.callGlobal("g", &.{}));
+}
+
 test "compiler: std.json.stringify serializes bigint as digits, not null; std.conv accepts bigint" {
     var rt = try setup();
     defer rt.deinit();
@@ -6698,6 +6745,125 @@ test "compiler: array/map element write re-enforces the named element type's pre
     try std.testing.expectEqual(@as(i64, 30), ok.int);
 }
 
+// Go-style typed composite-literal sugar for arrays: `[]Type{elem, ...}` as
+// a standalone expression. Desugars to the exact same construction
+// `var xs []Type = [elem, ...]` already compiles to (compiler_stmts.zig's
+// varDecl: an anonymous array named_type built once, its object pushed as
+// a constant, the plain array value constructed and passed to it as a
+// single-arg call) — verified here across primitive, struct, named-type,
+// empty, and nested element types, plus that element-type checking still
+// fires (an ill-typed element must still be rejected, not silently
+// accepted just because it went through the new sugar path).
+test "compiler: []Type{...} composite-literal sugar constructs a typed array" {
+    var rt = try setup();
+    defer rt.deinit();
+    try runSrc(&rt,
+        \\std := import("std")
+        \\type Point struct { x int, y int }
+        \\type Meters int
+        \\func ints() []int { return []int{1, 2, 3} }
+        \\func strs() []string { return []string{"a", "b", "c"} }
+        \\func emptyInts() []int { return []int{} }
+        \\func points() []Point { return []Point{Point{x: 1, y: 2}, Point{x: 3, y: 4}} }
+        \\func meters() []Meters { return []Meters{Meters(1), Meters(2)} }
+        \\func nested() [][]int { return [][]int{[]int{1, 2}, []int{3, 4}} }
+        \\func typeName() string { return std.core.type_of([]int{1, 2}) }
+    );
+    // A `[]T`-declared function return (like a `[]T`-declared local or
+    // param) is a named_value wrapping the plain array — unwrap before
+    // inspecting, same as the matchesTypeAlt fix this test also exercises.
+    const arraySlice = struct {
+        fn get(v: Value) ![]Value {
+            const inner = v.namedInner() orelse v;
+            return vms.asArraySlice(inner.object);
+        }
+    }.get;
+
+    const ints = try rt.callGlobal("ints", &.{});
+    const ints_items = try arraySlice(ints);
+    try std.testing.expectEqual(@as(usize, 3), ints_items.len);
+    try std.testing.expectEqual(@as(i64, 1), ints_items[0].int);
+
+    const strs = try rt.callGlobal("strs", &.{});
+    try std.testing.expectEqual(@as(usize, 3), (try arraySlice(strs)).len);
+
+    const empty = try rt.callGlobal("emptyInts", &.{});
+    try std.testing.expectEqual(@as(usize, 0), (try arraySlice(empty)).len);
+
+    const points = try rt.callGlobal("points", &.{});
+    try std.testing.expectEqual(@as(usize, 2), (try arraySlice(points)).len);
+
+    const meters = try rt.callGlobal("meters", &.{});
+    try std.testing.expectEqual(@as(usize, 2), (try arraySlice(meters)).len);
+
+    // A copy-paste-divergence audit found matchesTypeAlt's .array/.map
+    // cases never unwrapped a named_value before checking isArrayObject —
+    // this is exactly the shape `[][]int{...}` produces for each inner
+    // element (a named-array-typed value nested inside another array
+    // literal), so this specific assertion is the regression guard for
+    // that fix, not just the sugar's own construction.
+    const nested = try rt.callGlobal("nested", &.{});
+    const nested_items = try arraySlice(nested);
+    try std.testing.expectEqual(@as(usize, 2), nested_items.len);
+    try std.testing.expectEqual(@as(i64, 1), (try arraySlice(nested_items[0]))[0].int);
+
+    const tn = try rt.callGlobal("typeName", &.{});
+    try std.testing.expectEqualStrings("array", try vms.asStringValue(tn));
+
+    try std.testing.expectError(error.TypeError, runSrc(&rt, "bad := []int{1, \"two\", 3}"));
+}
+
+// Gengo is newline-insensitive, so a naive "identifier right after ']'
+// means a type name follows" check misfires on completely ordinary code:
+// `xs := []` (a complete statement, empty untyped array) directly followed
+// by an unrelated NEW statement that happens to start with an identifier
+// (`std.io.println(xs)`) used to be swallowed as if it were
+// `[]std...{...}`. The fix requires that identifier to actually be a known
+// type name (isKnownTypeName) before treating it as the sugar.
+test "compiler: []Type{...} sugar doesn't misfire on a plain [] followed by an unrelated statement" {
+    var rt = try setup();
+    defer rt.deinit();
+    try runSrc(&rt,
+        \\std := import("std")
+        \\empty := []
+        \\func describe() string { return std.core.type_of(empty) }
+    );
+    const result = try rt.callGlobal("describe", &.{});
+    try std.testing.expectEqualStrings("array", try vms.asStringValue(result));
+}
+
+// The same matchesTypeAlt fix as the nested-array assertion above, but
+// isolated to its actual trigger: a []T-typed function parameter receiving
+// an already []T-typed argument. Before the fix this failed with a
+// confusingly identical-looking "expected []int, got []int" (both sides
+// render the same runtime type name — the check just never looked past the
+// named_value wrapper constructNamedType's .array_t case always produces).
+// Reproduced via the plain `var` declaration form too, proving this was a
+// pre-existing bug in typed-array declarations generally, not something
+// the new []Type{} sugar introduced.
+test "compiler: a []T-typed value passes a []T-typed function parameter (named_value unwrapping)" {
+    var rt = try setup();
+    defer rt.deinit();
+    try runSrc(&rt,
+        \\func sum(xs []int) int {
+        \\    total := 0
+        \\    for v in xs {
+        \\        total += v
+        \\    }
+        \\    return total
+        \\}
+        \\func viaSugar() int { return sum([]int{10, 20, 30}) }
+        \\func viaVarDecl() int {
+        \\    var ys []int = [1, 2, 3]
+        \\    return sum(ys)
+        \\}
+    );
+    const a = try rt.callGlobal("viaSugar", &.{});
+    try std.testing.expectEqual(@as(i64, 60), a.int);
+    const b = try rt.callGlobal("viaVarDecl", &.{});
+    try std.testing.expectEqual(@as(i64, 6), b.int);
+}
+
 // Every other arithmetic-carrier path (add/sub/mul, unary neg, abs) re-checks
 // a named type's predicate after producing a new value; TypeName.succ/pred
 // (both the bound-function form and the method-call form) didn't, so

src/lang/compiler.zig

@@ -2740,6 +2740,7 @@ pub const Compiler = struct {
     const structInstanceLitAfterValue = compiler_expr.structInstanceLitAfterValue;
     const subtypeDecl = compiler_decls.subtypeDecl;
     const switchStmt = compiler_stmts.switchStmt;
+    pub const tryTypedArrayLit = compiler_stmts.tryTypedArrayLit;
     pub const typeNameLiteral = compiler_expr.typeNameLiteral;
     const unaryExpr = compiler_expr.unaryExpr;
     const varDecl = compiler_stmts.varDecl;

src/lang/compiler_expr.zig

@@ -56,6 +56,46 @@ pub fn arrayLit(c: anytype) !void {
     try c.cs.emit2(@intFromEnum(Op.build_array), count, c.prev.line);
 }
 
+// Entry point for parsePrecedence's `.lbracket` prefix arm — pulled out into
+// its own function (not inlined into that switch arm directly) so its 4
+// saved-position locals live in THIS function's stack frame, not
+// parsePrecedence's. parsePrecedence recurses on every nested expression
+// (e.g. unary minus chains), and in an unoptimized/Debug build each of its
+// local variables — regardless of which switch arm actually uses them —
+// contributes to every single recursive frame's size; found via a
+// pre-existing "expression too deep" test that verifies MaxExprDepth's
+// software counter rejects deep nesting before the native stack actually
+// overflows, which started hitting the real stack limit first once these
+// locals were briefly inlined there instead.
+//
+// Disambiguates `[]Type{...}` (the typed composite-literal sugar) from a
+// plain array literal `[elem, ...]` or an empty `[]`. '[' is already
+// consumed (it's c.prev); c.cur is ']' only for either shape, and whether a
+// real type spec (then '{') follows can only be known by actually trying to
+// parse one — Gengo is newline-insensitive, so `xs := []` immediately
+// followed by an unrelated NEW statement (starting with an identifier,
+// `func`, another `[`, anything) is completely ordinary code, not a broken
+// program, and token-type lookahead alone can't tell that apart from
+// genuine `[]Type{...}` sugar in general. tryTypedArrayLit only commits
+// (emits bytecode) once '{' is actually confirmed; on any other outcome it
+// consumes nothing beyond the ']' the caller already confirmed, so a plain
+// position save/restore is sufficient to cleanly fall back to ordinary
+// array-literal parsing.
+fn arrayLitOrTypedArrayLit(c: anytype) !void {
+    if (c.check(.rbracket)) {
+        const saved_cur = c.cur;
+        const saved_prev = c.prev;
+        const saved_peek = c.peek_tok;
+        const saved_lex = c.lex;
+        if (try c.tryTypedArrayLit()) return;
+        c.cur = saved_cur;
+        c.prev = saved_prev;
+        c.peek_tok = saved_peek;
+        c.lex = saved_lex;
+    }
+    try arrayLit(c);
+}
+
 // Returns true for an identifier token that names a concrete, comparable
 // type — usable opposite a '.type' expression. Interfaces are excluded
 // ('.type' never equals an interface name, since interfaces aren't concrete
@@ -893,7 +933,7 @@ pub fn parsePrecedence(c: anytype, p: Prec) anyerror!void {
         },
         .lbracket => {
             c.clearCurrentExprPrimInfo();
-            try arrayLit(
+            try arrayLitOrTypedArrayLit(
                 c,
             );
         },

src/lang/compiler_stmts.zig

@@ -2186,6 +2186,73 @@ fn fieldTypeAltLabel(hs: *heap.State, alt: FieldTypeAlt) []const u8 {
     };
 }
 
+// Sugar for `[]Type{elem, elem, ...}` as a standalone expression (Go-style
+// composite literal) — e.g. `xs := []int{1, 2, 3}`. Desugars to exactly the
+// same construction `var xs []int = [1, 2, 3]` already compiles to below
+// (an anonymous array named_type built once, its object pushed as a
+// constant, the plain array value constructed and passed to it as a
+// single-arg call) — reusing that machinery rather than duplicating its
+// element-type checking/coercion rules a second time.
+//
+// Entered only from parsePrecedence's `.lbracket` prefix arm, which has
+// already consumed the leading '[' (it's in c.prev) and confirmed c.cur is
+// ']' — that's it; whether a real type spec (and then '{') follows can only
+// be known by actually trying to parse one, since Gengo is newline-
+// insensitive and a plain `[]` is a complete expression on its own (e.g.
+// `xs := []` immediately followed by an unrelated new statement that
+// happens to start with `func`/an identifier/another `[` is completely
+// ordinary code, not a broken program).
+//
+// Returns false (having consumed NOTHING beyond confirming c.cur is ']')
+// when this isn't actually the sugar shape — parseFieldTypeSpec errored, or
+// no '{' follows the parsed type — so the caller can roll back to exactly
+// where it started and fall back to treating '[]' as a plain empty array.
+// Every side effect below this point (heap bumps for the FieldTypeSpec
+// tree, c.setErr from a failed speculative parse) is either harmless to
+// discard (compile-time-only scratch data) or gets overwritten by whatever
+// real error the fallback path produces — see this function's caller for
+// the actual state save/restore. Nothing is emitted to c.cs (bytecode)
+// until AFTER the '{' is confirmed, so there is never anything to unwind
+// on the chunk side.
+pub fn tryTypedArrayLit(c: anytype) !bool {
+    const open_line = c.prev.line;
+    c.advance(); // consume ']' of the leading '[]' (caller already confirmed it)
+    const elem = c.parseFieldTypeSpec() catch return false;
+    if (c.cur.typ != .lbrace) return false;
+    const ep = c.hs.bump(FieldTypeSpec, 1) orelse return error.OutOfMemory;
+    ep[0] = elem;
+    const array_alt: FieldTypeAlt = .{ .typ = .array, .elem_spec = ep[0] };
+    const type_label = fieldTypeAltLabel(c.hs, array_alt);
+    const nt = c.hs.allocObject() orelse return error.OutOfMemory;
+    nt.* = .{ .named_type = .{
+        .name = type_label,
+        .qualified_name = type_label,
+        .base = .array_t,
+        .is_anonymous = true,
+        .elem_spec = ep[0],
+    } };
+    try c.cs.emitConst(.{ .object = nt }, open_line);
+
+    c.advance(); // consume '{' (caller already confirmed it via c.cur.typ == .lbrace)
+    var count: u8 = 0;
+    if (!c.check(.rbrace)) {
+        while (true) {
+            try c.expr();
+            if (count == 255) {
+                c.setErr("too many elements (max {d})", .{MaxLocals});
+                return error.TooManyElements;
+            }
+            count += 1;
+            if (!c.match(.comma)) break;
+            if (c.check(.rbrace)) break;
+        }
+    }
+    try c.consume(.rbrace);
+    try c.cs.emit2(@intFromEnum(Op.build_array), count, c.prev.line);
+    try c.cs.emitCall(1, open_line);
+    return true;
+}
+
 pub fn varDecl(c: anytype, has_keyword: bool, is_const: bool) !void {
     if (has_keyword and c.cur.typ != .ident) return c.err("expected identifier, found {s}", .{c.tokenName(c.cur.typ)});
     const name = c.cur;