メニュー
Run the Spice `spicetest` suite (GoogleTest-based integration + unit tests). Use when the user wants to run all tests, a specific suite or case, update reference files, check for memory leaks with valgrind, or debug a failing test.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Build the Spice compiler (`spice`) and/or the test runner (`spicetest`) with CMake/Ninja. Use when the user wants to compile/rebuild the project, build a specific target, produce a release/debug build, or set up the CMake build directory before running or testing.
Guidelines for contributing changes to the Spice GitHub repository — branch naming conventions, commit message format, PR workflow, no-push-to-main rule, and quality gates. Use when preparing a branch for review, writing a commit, opening a PR, or checking that a contribution is ready to merge.
Profile and benchmark the Spice compiler (the host C++ `spice` program) and the native binaries it emits from `.spice` files — using the built-in per-stage timers, the dedicated CMake profiling build options, and external tools (perf, valgrind/callgrind, flamegraph, hyperfine). Covers the preferred build/compile settings for representative profiling of each layer. Use when the user wants to find where compile time or runtime is spent, benchmark a change, or chase a performance regression.
Find, diagnose, and fix bugs in the Spice compiler or in a compiled Spice program using GDB, objdump, sanitizers (for both the host C++ compiler and the emitted Spice program via the built-in `--sanitizer` flag), the compiler dump flags, and valgrind. Use when investigating a crash, miscompilation, memory error, or undefined behavior, or when triaging a failing test. Whenever a bug is fixed, this skill also requires extending or adding a test that covers the problematic code path and any related uncovered paths.
Add a reference/integration test case under test/test-files for the Spice compiler. Covers the directory layout (flat vs grouped suites), the exact reference filenames the runner compares against, control/skip marker files, platform-specific variants, and the --update-refs workflow to generate expected output. Use when adding or modifying compiler test cases.
Orientation map of the Spice compiler codebase — the compilation pipeline (lexer → parser → CST → AST → import collector → symbol table → type checker → IR generator → optimizer → object emitter → linker), the key class/file for each stage, and the SourceFile orchestration sequence. Use when navigating the compiler, deciding where a change belongs, or understanding how a stage feeds the next.
| name | spice-test |
| description | Run the Spice `spicetest` suite (GoogleTest-based integration + unit tests). Use when the user wants to run all tests, a specific suite or case, update reference files, check for memory leaks with valgrind, or debug a failing test. |
spicetest is a GoogleTest binary built from test/. It drives two kinds of
tests:
test/test-files/<group>/.... Each test case dir has a source.spice plus
reference files the runner compares against (see below).test/unittest/ (e.g. BlockAllocatorTest, CommonUtilTest).Build it first (see the spice-build skill):
cmake --build cmake-build-debug --target spicetest.
The binary lands at cmake-build-debug/test/spicetest.
# All tests
cmake-build-debug/test/spicetest
# List every test name (best way to find an exact filter)
cmake-build-debug/test/spicetest --gtest_list_tests
# Filter by suite or case (GoogleTest globbing)
cmake-build-debug/test/spicetest --gtest_filter='IRGeneratorTests*'
cmake-build-debug/test/spicetest --gtest_filter='CommonUtilTest.*'
cmake-build-debug/test/spicetest --gtest_filter='*ForLoop*'
Reference-test suites (instantiated from test/test-files/<group>):
CommonTests, LexerTests, ParserTests, SymbolTableBuilderTests,
TypeCheckerTests, IRGeneratorTests, StdTests, BenchmarkTests,
ExampleTests, BootstrapCompilerTests.
These are spicetest's own flags (not GoogleTest):
--update-refs — regenerate/overwrite reference files from current output.
Use after an intentional change to compiler output, then review the diff.--run-benchmarks — also run benchmark cases and check baselines.--leak-detection — wrap tests in valgrind to detect leaks.--skip-sanitizer-tests — skip tests exercising language sanitizers.--is-github-actions — skip cases unsupported on CI.--verbose — extra runner debug output.# Update refs for one suite after an intended change, then inspect git diff
cmake-build-debug/test/spicetest --gtest_filter='IRGeneratorTests*' --update-refs
git diff test/test-files
# Valgrind on a focused set (full run is slow)
valgrind --leak-check=full cmake-build-debug/test/spicetest --gtest_filter='ParserTests*'
# Or the dedicated build target
cmake --build cmake-build-debug --target spicetest_leakcheck
# Debug a failing case under gdb
gdb --args cmake-build-debug/test/spicetest --gtest_filter='TypeCheckerTests*'
Common files the runner reads/compares (presence is optional per case):
source.spice (+ source1.spice, …) — input programcout.out — expected stdout; exception.out / warning.out — expected errors/warningsexit-code.out — expected process exit codeir-code.ll, ir-code-O2.ll, ir-code-O3.ll, … — expected LLVM IR per opt levelassembly-linux-amd64.asm, assembly-linux-aarch64.asm — expected assemblysymbol-table.json, type-registry.out — expected symbol/type dumpssyntax-tree.dot / parse-tree.dot / dependency-graph.dot — expected graphs*-windows.*, *-macos.*, skip-windows,
skip-gh-actions, run-builtin-tests, cli-flags.txtTo produce these dumps manually for a single input, use the spice-dump skill.