feat(struct): add StructDef and dot-access MVP

[thiremani]

Summary

• add Phase 1 StructDef support in .pt using header-row + single value row syntax
• add .spt dot field access (p.name) with parser/type-solver/compiler support
• store struct constants as LLVM named struct globals and extract fields via extractvalue
• enforce duplicate struct type rejection and duplicate struct field header rejection
• keep struct metadata in Code.Struct (parallel to Code.Const and Code.Func)
• align struct type mangling/demangling to nominal type form (no Struct_ namespace prefix)

Syntax covered

p = Person
    :name age height
    "Tejas" 35 184.5

p.name, p.age, p.height

Implementation notes

• lexer: . tokenization with .5 float compatibility
• AST: StructLiteral, DotExpression, StructDef container
• parser: struct literal parsing in code mode; dot postfix parsing in script mode
• compiler/types/solver/cfg: struct kind/type handling + field access typing + traversal support
• formatting: friendlier direct-struct print diagnostic

Tests

• go test ./...
• python3 test.py tests/struct
• python3 test.py

[thiremani]

Code Review: codex/structdef-on-master

Solid PR — the struct definition, constant compilation, and dot-access MVP is well-structured with good test coverage (345 lines of compiler tests, parser tests, and an E2E integration test). The two-pass canonical-definition approach and reserved-name consolidation are clean design decisions. A few issues to address:

---

1. TypeStructLiteral leaves FieldSet nil on solver-inferred Struct

Severity: Important (latent bug) | Confidence: 88%

compiler/solver.go ~line 820:

structType := Struct{
    Name:   sl.Token.Literal,
    Fields: fields,
    // FieldSet is nil!
}

buildStructDef in codecompiler.go correctly initializes FieldSet, but the solver path doesn't. Currently safe because compileDotExpression and TypeDotExpression both use Fields (not FieldSet), but any future code that calls FieldSet[name] on a solver-derived struct type will silently return "not found" for valid fields. This inconsistency between the two Struct construction sites is a trap.

Fix:

fieldSet := make(map[string]struct{}, len(fields))
for _, f := range fields {
    fieldSet[f.Name] = struct{}{}
}
structType := Struct{
    Name:     sl.Token.Literal,
    Fields:   fields,
    FieldSet: fieldSet,
}

---

2. cfg.checkWrite / cfg.isDefined will panic if CodeCompiler is nil

Severity: Latent critical | Confidence: 85%

compiler/cfg.go lines ~439 and ~491 unconditionally dereference cfg.CodeCompiler:

cc := cfg.CodeCompiler
if _, ok := cc.Code.ConstNames[e.Name]; ok {  // panic if cc == nil

NewCFG accepts a nil CodeCompiler and Analyze is public. A nil-CodeCompiler CFG that processes any write event will nil-panic. Currently all call sites pass a non-nil CodeCompiler, but this is a fragile contract.

Fix: Add a nil guard:

if cc := cfg.CodeCompiler; cc != nil {
    if _, ok := cc.Code.ConstNames[e.Name]; ok {
        cfg.addError(e.Token, ...)
    }
}

---

3. collectStructDefs: Ambiguous same-arity definitions produce confusing error messages

Severity: Important (UX) | Confidence: 82%

compiler/codecompiler.go ~lines 135-140:

if !exists || len(stmt.Value.Headers) > len(existing.Fields) {
    def, defErrs := buildStructDef(stmt)
    defs[typeName] = def
}

When two full-length definitions have the same field count, first-seen silently wins. The second is then validated as a "usage" — producing either "field X not in struct type Y" (non-overlapping fields) or "ambiguous struct field order" (same fields, different order). Both are technically correct rejections, but misleading to users who wrote what they intended as two separate definitions.

Consider detecting tied-max and emitting a dedicated "conflicting struct definition for type X" error. No test covers the equal-arity-different-fields case.

---

4. Code.Merge — Struct.Map retains first-merged entry regardless of field count

Severity: Latent (minor) | Confidence: 85%

ast/ast.go ~line 81:

maps.Copy(c.Struct.Map, other.Struct.Map)

maps.Copy destination-wins semantics means Struct.Map keeps the first-merged entry for a type name, even if a later-merged file has the canonical (max-header) definition. Currently harmless because collectStructDefs works from Struct.Statements, not Struct.Map. But Struct.Map now misrepresents the canonical definition — any future caller relying on it will get the wrong answer.

---

5. bounds.go — nil-check removal on onElse

Severity: Low | Confidence: 80%

compiler/bounds.go line ~87: The nil-check on onElse was removed. All current callers pass a non-nil callback, but this narrows the contract of withGuardedBranch silently. If this is intentional (all callers must provide onElse), consider documenting it; otherwise restore the guard.

---

Minor observations

• Struct alignment (compiler.go ~line 979): Hardcoded to 8 bytes is correct for Phase 1 scalar/pointer fields, but will need revisiting if nested structs or smaller-than-pointer field types are added.
• Test quality: Excellent coverage of edge cases — ambiguous order, unknown fields, type mismatch, reserved names, empty init before definition. The TestStructUnknownFieldNoSpuriousError test is particularly good defensive testing.
• parseStructRowConstants: The comma handling is a nice touch for future flexibility, but currently structs use space-separated values. If commas aren't part of the syntax yet, consider whether the comma path is dead code or intentional forward-compatibility.

---

Overall this is a clean, well-tested MVP. Issues 1 and 3 are the most actionable. Nice work! 🎯