Some checks failed
Test, Build, and Deploy / test-build-deploy (push) Failing after 28s
Phase 3 cont. Adds go-check-decl which dispatches on AST shape and
returns either the extended context or a :type-error:
:var-decl (:field NAMES TYPE-or-nil) EXPRS-or-nil
:const-decl (same shape; same logic in v0 — mutability later)
:short-decl LHS-LIST EXPRS (lhs is a list of :var nodes)
:type-decl NAME TYPE (type alias)
New helpers:
go-default-type — untyped-int → int, untyped-float → float64,
etc. Used when inferring var x = EXPR.
go-check-exprs-against — every expr assignable to the declared type.
go-bind-names-to-synth — pair names with default-typed synth of
corresponding exprs; extends ctx.
The canonical Go pitfall flows through end-to-end now:
(go-check-decl ctx (go-parse "var x float64 = 42 / 7"))
→ ctx + (x → float64)
Because: 42/7 synthesises to ty-untyped-int (binop result of two
untyped operands), then go-check-exprs-against uses go-type-assignable?
to check ty-untyped-int → ty-name "float64" — :ok via the
untyped-int-to-any-numeric assignability rule. The 6 (integer) result
gets float-converted on assignment, never floated mid-computation.
types 40/40, total 345/345.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
15 lines
491 B
JSON
15 lines
491 B
JSON
{
|
|
"language": "go",
|
|
"total_pass": 345,
|
|
"total": 345,
|
|
"suites": [
|
|
{"name":"lex","pass":129,"total":129,"status":"ok"},
|
|
{"name":"parse","pass":176,"total":176,"status":"ok"},
|
|
{"name":"types","pass":40,"total":40,"status":"ok"},
|
|
{"name":"eval","pass":0,"total":0,"status":"pending"},
|
|
{"name":"runtime","pass":0,"total":0,"status":"pending"},
|
|
{"name":"stdlib","pass":0,"total":0,"status":"pending"},
|
|
{"name":"e2e","pass":0,"total":0,"status":"pending"}
|
|
]
|
|
}
|