Compiler
Lexer, parser, AST, semantic analysis, code generation, diagnostics, and command-line behavior.
Open source
Neo is open source.
The compiler, runtime, interpreter written in Neo, tests, examples, and documentation are all on GitHub.
Ways to contribute
Pick a part of the project and improve it.
A focused compiler or runtime change should include a small Neo regression test.
Runtime
Vectors, strings, command-line arguments, comparisons, I/O, matrices, statistics, and numerical operations.
Language design
Semantics, edge cases, specification alignment, and small proposals grounded in implementation.
Interpreter
Lexer, parser, evaluator, persistent environments, REPL behavior, and compiler/interpreter consistency.
Testing
Regression cases, compile failures, runtime failures, conformance coverage, and known-bug isolation.
Documentation
Examples, reference material, specification corrections, migration notes, and tutorials.
Tooling
Editor support, syntax highlighting, formatter work, package ideas, build and release automation.
Systems
Embedded targets, robotics, device APIs, vendor SDK wrappers, and C/C++ interoperability.
Numerical work
Data processing, complex numbers, quaternions, matrices, AI primitives, and performance.
Tests are part of the change
Put each behavior in the right suite.
pass/Programs that should compile and run.
compile_fail/Programs the compiler must reject.
runtime_fail/Programs that compile but fail at runtime.
known_failures/Active compiler bugs kept visible until fixed.
cmake -S . -B build -G Ninja \ -DCMAKE_BUILD_TYPE=Release cmake --build build .\build\neo.exe tests\v3\neo-full-regression.neo \ neo-full-regression.exe .\neo-full-regression.exe
Working agreement
Keep changes small and test them.
01When the specification and compiler differ, document the mismatch instead of weakening the test silently.
02Prefer a small, focused change with one clear behavior over a broad patch that hides several decisions.
03Keep generated executables and C++ output out of Git. Commit the source, test, and documentation.
04Use issues for bugs and design questions. Use pull requests for concrete, test-backed changes.