tree-sitter-c

tree-sitter-c is the official C language grammar for tree-sitter, the incremental parsing framework used by editors and developer tools to build fast, error-tolerant syntax trees. It defines C’s grammar in grammar.js, which tree-sitter compiles into a generated C parser (src/parser.c) that can be embedded in any host language via tree-sitter’s language bindings.

The repository ships first-party bindings for Rust, Node.js, Python, Go, Swift, and Zig, so the same grammar can be consumed from editors, linters, or static-analysis tools written in any of those ecosystems. It also includes highlight and structural queries (queries/) used by editors like Neovim, Zed, and Helix to drive syntax highlighting and code navigation for C source files.

What You Get

• A complete C grammar (grammar.js) covering declarations, expressions, statements, types, and the C preprocessor
• A generated, dependency-free C parser (src/parser.c) compiled from the grammar for use by the tree-sitter runtime
• First-party language bindings for Rust, Node.js, Python, Go, Swift, and Zig
• Highlight and tag queries (queries/) that editors use for syntax highlighting, code folding, and symbol navigation
• A corpus-based test suite (test/corpus) covering ambiguous grammar cases, preprocessor directives, and Microsoft-specific C extensions

Common Use Cases

• Powering syntax highlighting and code navigation for C files in editors like Neovim, Zed, Helix, or Atom
• Building a static analysis or linting tool that needs an accurate, incrementally-updatable C syntax tree
• Implementing structural code search or refactoring tooling that queries C source via tree-sitter’s query language
• Embedding a C parser in a Rust, Python, Go, or Node.js application via the official language bindings

Under The Hood

Architecture - The grammar is authored once in grammar.js using tree-sitter’s JavaScript DSL, then compiled offline into a generated src/parser.c (a table-driven GLR-style parser) plus node-types.json/grammar.json metadata describing the resulting syntax tree shape. Each bindings/<language> directory is a thin wrapper that links against this generated C parser and exposes it through that language’s native FFI conventions — the Rust binding (bindings/rust/lib.rs) compiles parser.c via a cc-based build script and links it through the tree-sitter-language crate.

Tech Stack - The Rust crate has a minimal footprint: tree-sitter-language as its only runtime dependency and cc as a build-time dependency to compile the generated C source, with tree-sitter itself only needed as a dev-dependency for running tests. The repository as a whole spans six language ecosystems (Cargo, npm, PyPI, Go modules, Swift Package Manager, Zig) all built from the single shared grammar source.

Code Quality - Correctness is validated through a corpus-based test suite (test/corpus) with dedicated files for ambiguous constructs, CRLF line endings, Microsoft-specific C extensions, and the preprocessor — an approach well-suited to grammar development where regressions typically show up as specific parse-tree shape changes rather than exceptions. The generated parser.c itself isn’t meant to be hand-edited; all real changes flow through grammar.js and get regenerated, keeping the source of truth single and auditable.

API Design - Consumers interact with the crate through tree-sitter’s standard Language/Parser API (tree_sitter_c::LANGUAGE), which is consistent across every tree-sitter grammar crate, so switching between or combining multiple language grammars in the same host application requires no per-grammar API relearning.