This is a MoonBit project.
You can browse and install extra skills here: https://github.com/moonbitlang/skills
-
MoonBit packages are organized per directory; each directory contains a
moon.pkgfile listing its dependencies. Each package has its files and blackbox test files (ending in_test.mbt) and whitebox test files (ending in_wbtest.mbt). -
The toplevel directory holds a
moon.workworkspace manifest with two member modules, each with its ownmoon.mod:bobzhang/cfrontundercfront/is the reusable C front end:target,ctype,preprocessor, andparser. It must not depend on anything inkimicc, and builds and tests standalone.bobzhang/kimiccat the root is the compiler: MIR, both code generators, the JIT, and the driver. It depends oncfront.
Root
moon check,moon test,moon fmt, andmoon infocover both modules. Package paths on the command line are prefixed by the owning module, so the parser iscfront/parser, notparser.
This project targets native ARM64 macOS. Use --target native for all builds
and tests. The native target produces a main.exe binary (~20x faster than wasm-gc).
moon build --target native
moon test --target native
moon run cmd/main --target native -- "<source code>"The compiler reads C source code from command-line argument args[1]:
# Using moon run
moon run cmd/main --target native -- "$(cat input.c)" > out.s
# Using the native binary directly
_build/native/debug/build/bobzhang/kimicc/cmd/main/main.exe "$(cat input.c)" > out.s
# Link with clang
clang -o out out.s && ./out-
MoonBit code is organized in block style, each block is separated by
///|, the order of each block is irrelevant. In some refactorings, you can process block by block independently. -
Try to keep deprecated blocks in file called
deprecated.mbtin each directory.
-
moon fmtis used to format your code properly. -
moon ideprovides project navigation helpers likepeek-def,outline, andfind-references. See $moonbit-agent-guide for details. -
moon infois used to update the generated interface of the package, each package has a generated interface file.mbti, it is a brief formal description of the package. If nothing in.mbtichanges, this means your change does not bring the visible changes to the external package users, it is typically a safe refactoring. -
In the last step, run
moon info && moon fmtto update the interface and format the code. Check the diffs of.mbtifile to see if the changes are expected. -
Run
moon test --target nativeto check tests pass. MoonBit supports snapshot testing; when changes affect outputs, runmoon test --updateto refresh snapshots. -
Prefer
assert_eqorassert_true(pattern is Pattern(...))for results that are stable or very unlikely to change. Use snapshot tests to record current behavior. For solid, well-defined results (e.g. scientific computations), prefer assertion tests. You can usemoon coverage analyze > uncovered.logto see which parts of your code are not covered by tests.