Compiler correctness claims are cheap. This page describes what actually runs, so you can judge how much weight the claims on this site carry.
The corpus
| Test programs | 1,640 |
| Declared test cases | 10,164 |
| Programs run on both architectures | 1,604 |
| Mica source under test | 217,661 lines across 1,732 files |
Each program carries a manifest declaring what to compile, how, and what to expect. One program declares many runs — a typical execution test declares twelve, covering six optimization configurations across both architectures. That is what the test-case figure counts.
Categories cover execution output, intermediate-language shape, generated assembly, expected compile errors, debugger behaviour, and export determinism.
The scale of the thing
| Compiler | 184,558 lines of Go across 712 files |
| Standard library and runtime | 19,212 lines across 36 files |
| Test harness | 12,951 lines of Go across 48 files |
| Test programs | 217,661 lines of Mica across 1,732 files |
The last row is larger than the first. There is more Mica under test than there is Go doing the compiling, which is the ratio we want and the reason the figures are published rather than summarised: a corpus that grows more slowly than the compiler is a corpus falling behind.
The standard library is counted on its own because most of it is written in Mica — the compiler compiles its own library — and folding it into either the compiler or the test figure would hide that.
Every number on this page is read out of the repository by a script at release time. None of them is typed by hand.
Axes under test
Programs are not merely run once and diffed. They are swept across:
- Optimization profiles — debug, checked, release
- Individual passes — constant folding, peephole, inlining, loop optimization, SSA versus direct lowering, graph versus stub allocation
- Architecture — x86_64 and AArch64
- String encoding — UTF-8 and UTF-32, which is a per-binary property
- Deployment class — including the fixed-arena allocator
- Carrier count — single and multicore
Optimizer statistics are themselves pinned as expectations. If a change causes the inliner to decline a site it used to accept, or the peephole pass to fire a different number of times, the suite notices — so a silent performance regression is a test failure rather than something discovered in a benchmark months later.
The merge gate
Nothing merges without the full ladder, which runs three suites concurrently in isolated workspaces:
- Stress — the full corpus through the compiler binary.
- Direct lowering — the same corpus through the legacy non-SSA path, kept green deliberately as a differential oracle against the SSA path. Two independent lowerings that must agree is a strong check on both.
- Race — the corpus through an in-process driver with Go’s race detector armed, which is the only mode that puts the compiler’s own concurrency under scrutiny.
A fourth sequential gate sweeps the multicore corpus for equivalence against the sequential build. The gate passes only if every suite does.
A compiler warning fails the suite. There is no accumulating backlog of tolerated diagnostics.
Quality gates inside the compiler
Separately from tests, the compiler validates its own invariants at three checkpoints: after semantic analysis, after intermediate-code generation, and after placement. These are not assertions left in by accident — they exist to root-cause internal compiler errors at the phase that introduced them rather than at the phase that tripped over the result.
Figures as of 2026-08-05, compiler 6.12.8. Gate results from the 6.12.7 release record: stress 10,164/0, direct lowering 10,079/0, race 10,079/0, multicore 274/0.