testsuite
Skill3.7k starsChanged 3 months agoMITView on GitHub
Verona compiler test suite infrastructure — running tests, updating golden files, verifying pass completeness, checking error codes. Use when debugging test failures, regenerating golden files, or understanding the test framework.
Trending
Quiet this year.about the whole repository
Who's talking about microsoft/verona
- A Hacker News story“Microsoft Project Verona: Research programming language for concurrent ownership”Hacker News · Jan 17, 2020 · 142 points
- A Hacker News story“Project Verona FAQ”Hacker News · Feb 10, 2020 · 29 points
- A Hacker News story“Project Verona: Research programming language for concurrent ownership”Hacker News · Jan 16, 2020 · 7 points
- A Hacker News story“Microsoft/Verona”Hacker News · Jan 18, 2020 · 3 points
- A Hacker News story“Concurrent Ownership in Verona”Hacker News · Dec 14, 2022 · 2 points
The biggest 5 of 18 mentions linking to the repository that our crawl found. Each line is their own headline.
See all 18
Talked about on GitHub and Hacker News (18 times).
On GitHub · 12
- Dec 31, 2023Check ideas from Verona language for concurrency — lambdaclass/concrete0 reactions
- Jul 21, 2023Add Verona — ChessMax/awesome-programming-languages0 reactions
- Jul 13, 2023Move the Verona compiler to microsoft/verona — microsoft/Trieste0 reactions
- Oct 24, 2022Optimise for waking an empty queue — microsoft/verona-rt0 reactions
- Oct 24, 2022Token source — microsoft/verona-rt0 reactions
7 more on GitHub
- Oct 20, 2022Small optimisations and refactors around message send and receive — microsoft/verona-rt0 reactions
- Jul 29, 2022Don't run CI on doc-only changes — microsoft/CCF0 reactions · 4 comments
- Aug 26, 2021Enable passthrough to an underlying allocator — microsoft/snmalloc0 reactions · 1 comment
- Jan 25, 2021Meta: Some interesting pointers to borrow ideas — flix/flix0 reactions · 1 comment
- Jan 4, 2021Meta: Some interesting pointers to borrow ideas — HigherOrderCO/Kind0 reactions
- Jun 18, 2020Refactor Pal and LargeAlloc interaction. — microsoft/snmalloc0 reactions
- Jan 27, 2020Automating keeping snmalloc up to date. — SchrodingerZhu/snmalloc-rs0 reactions · 2 comments
On Hacker News · 6
- Jan 17, 2020Microsoft Project Verona: Research programming language for concurrent ownership142 points · 16 comments
- Feb 10, 2020Project Verona FAQ29 points · 8 comments
- Jan 16, 2020Project Verona: Research programming language for concurrent ownership7 points
- Jan 18, 2020Microsoft/Verona3 points
- Dec 14, 2022Concurrent Ownership in Verona2 points
1 more on Hacker News
- Sep 17, 2023Microsoft Project Verona, a research programming language1 point
In this repository19 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- add-testSkill
- debugSkill
- docs-updateSkill
- reviewSkill
- vbci-memorySkill
- verona-codingSkill
- verona-conventionsSkill
- verona-type-inferenceSkill
- add-testSkill
- docs-updateSkill
- reviewSkill
- testsuiteSkill
- vbci-memorySkill
- verona-codingSkill
- verona-conventionsSkill
- verona-type-inferenceSkill
The file
Files
Verona Test Suite Guide
Test Infrastructure Overview
The test suite uses Trieste's testsuite.cmake framework. Tests are defined in testsuite/CMakeLists.txt, which calls testsuite(vbc). Two collection files define complete compile/run pipelines:
| Collection | File | Pipeline | Input |
| vc | testsuite/vc.cmake | Verona → bytecode → execute | *.v files |
| vir | testsuite/vir.cmake | IR → bytecode → execute | *.vir files |
Each collection owns its compiler invocation and registers a dependent
interpreter node. Sources under a compile_only/ directory register only the
compile node.
Each test produces exit_code.txt, stdout.txt, and stderr.txt in its output directory. The vc layer also produces per-pass .trieste dump files, a *_final.trieste, and a .vbc file (on success).
Running Tests
Full test suite
cd build && ctest --output-on-failure -j$(nproc)
### Run specific test(s) by name
```bash
cd build && ctest --output-on-failure -R "^vbc/<name>" -j$(nproc)The ^vbc/ prefix matches both compile and run tests for a given name. For example, ^vbc/hello matches:
vbc/hello/hello/compile(the compilation test)vbc/hello/hello/compile-exit_code.txt(exit code comparison)vbc/hello/hello/compile-stdout.txtetc.vbc/hello/hello/run(the runtime test, if it exists)vbc/hello/hello/run-exit_code.txtetc.
Run only compile or only runtime tests
cd build && ctest --output-on-failure -R "compile" -j$(nproc) # all compile tests
cd build && ctest --output-on-failure -R "run" -j$(nproc) # all runtime testsList available tests without running
cd build && ctest -N | grep <name>Golden Files
Structure
Each test testsuite/v/<name>/<name>.v has golden files at:
testsuite/v/<name>/<name>/compile/— compilation golden outputtestsuite/v/<name>/<name>/run/— runtime golden output (success tests only)
Expected compile/ contents (success tests)
00_parse.trieste # Pass 0 output
01_structure.trieste # Pass 1 output
02_ident.trieste # Pass 2 output
03_sugar.trieste # Pass 3 output
04_functype.trieste # Pass 4 output
05_dot.trieste # Pass 5 output
06_application.trieste # Pass 6 output
07_anf.trieste # Pass 7 output
08_infer.trieste # Pass 8 output
09_reify.trieste # Pass 9 output
10_assignids.trieste # Pass 10 output
11_validids.trieste # Pass 11 output
12_liveness.trieste # Pass 12 output
13_typecheck.trieste # Pass 13 output
<name>_final.trieste # Final AST
<name>.vbc # Compiled bytecode
exit_code.txt # "0" (no trailing newline)
stdout.txt # Usually empty
stderr.txt # Usually emptyExpected compile/ contents (error tests)
Same pass dumps up to the point of failure. No .vbc file. exit_code.txt = 1.
Expected run/ contents
exit_code.txt # Expected exit code (no trailing newline)
stdout.txt # Expected stdout
stderr.txt # Expected stderr (usually empty)Regenerating golden files
When source code changes, the golden files must be regenerated:
cd build
ninja install && ninja update-dumpninja install— rebuild the compiler (needed so installed binary has_builtin)ninja update-dump— regenerates golden output by running each test and copying results
When ALL golden files change
Adding or modifying a .v file under vc/_builtin/ changes compilation output for EVERY test, because _builtin is always parsed. In this case, you MUST regenerate ALL golden files:
cd build && ninja install && ninja update-dumpThis can take a while. All golden file changes must be committed.
Verifying Golden File Correctness
Pass completeness check
After generating golden files, verify the compile/ directory has all 14 pass dumps (00_parse.trieste through 13_typecheck.trieste). Missing passes indicate a WF (well-formedness) violation or pass failure.
Common causes of missing passes:
- New token/op not added to the relevant WF definition in
vc/lang.h(frontend WFs) orinclude/vbcc.h(backend WFs) - WF mismatch between what a pass produces and what the next pass expects
Debugging missing passes:
cd build && dist/vc/vc build ../testsuite/v/<name> --dump_passes=dump_<name>This dumps each pass output to the given directory. Check which pass produces the last .trieste file — the next pass is the one that fails.
Exit code verification
exit_code.txtcontains the exit code as a plain number with NO trailing newline- The file is generated by cmake's
file(WRITE ...)which doesn't append a newline - Success compile tests:
0 - Error compile tests:
1 - Runtime tests: depends on what
mainreturns (typically0for passing tests)
Checking for correct error codes
For compile-error tests, verify:
compile/exit_code.txtcontains1- No
run/directory exists (compilation failed, nothing to run) - No
.vbcfile incompile/(compilation didn't produce output) stderr.txtmay contain error messages (but the framework doesn't validate error messages, only exit codes)
For runtime tests with expected non-zero exit codes:
run/exit_code.txtcontains the expected value- The bitmask pattern (
result + 1,result + 2,result + 4, ...) helps diagnose which checks failed
How the Framework Works
Test execution flow
- Trieste discovers each collection file (for example,
vc.cmake) - Its
TESTSUITE_DEFINEcallback registers a named node for each selected input - CTest runs Trieste's node executor with the registered command
- stdout →
stdout.txt, stderr →stderr.txt, exit code →exit_code.txt - Declared artifacts are checked and declared goldens are compared
- Dependent run nodes execute only after their compile nodes pass
Golden file comparison
- Each file declared in
GOLDENSis compared with the corresponding output - Comparison ignores line-ending differences
- If a file differs, the node fails and shows a diff
exit_code.txt,stdout.txt, andstderr.txtare declared for every node
Test naming convention
Tests are named hierarchically: vbc/<name>/<name>/compile and vbc/<name>/<name>/run.
Each node is one CTest test. Run nodes declare their compile node in DEPENDS, so
CTest runs and verifies compilation first.
Common Pitfalls
- Forgot
ninja install: The build binary atbuild/vc/vcdoes NOT have_builtinnext to it. Onlybuild/dist/vc/vcdoes. Alwaysninja installbeforeupdate-dump. - Build was not regenerated: Re-run
ninjaafter adding a test so CMake's configured file globs discover it. - Stale golden files: Remove files explicitly when they are no longer declared as golden outputs.
- Hidden
.vbcfile: Runningvc build .from inside a test directory produces.vbc(hidden file) because the project name is ".". Always run frombuild/:dist/vc/vc build ../testsuite/v/<name>. - Timeout failures: Tests that hang (infinite loops, deadlocks) are killed after 20 seconds and produce a non-zero exit code. The
exit_code.txtwill contain a timeout error string, not a number. - New
_builtinfiles: Changes tovc/_builtin/affect ALL tests. Must regenerate all golden files and commit all changes. - Missing pass dumps: Usually a WF violation. Check which pass is the last one that produced output and investigate the next pass's WF definition.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

