Testing and Verification
How the team keeps the language, the interpreter, and the native compiler in sync.
Interpreter oracle
The interpreter is the reference behaviour for the language.
Whenever the native path grows a new lowering or a new runtime representation, the interpreter stays around to answer the one question that matters most: does this still behave like the language says it should?
- It covers parse, check, and execute flows.
- It keeps the language contract visible when backend work is still incomplete.
- It is the thing the native compiler is tested against, not replaced by.
Differential testing
A compiled program should agree with the interpreter on output and exit status.
- The harness runs the same example through both execution paths.
- Any divergence is a signal that a lowering or runtime detail drifted.
- This is especially important for phases that transform control flow or ownership.
Test layers
Different features deserve different checks, and the docs should say which one is authoritative.
- Parser and checker tests catch syntax and typing mistakes.
- Ownership and MIR tests catch the hard semantic bugs.
- Example programs act as documentation and regression cases at the same time.
Fast loop
Use the smallest useful command first, then broaden when the change proves it needs more coverage.
- Website changes: the front-end check first.
- Language changes: the focused test plus the example that demonstrates the feature.
- Compiler changes: the phase-specific battery and the differential harness.