clice

A C/C++ language server written in modern C++, and more than a language server. Like clangd and ccls it is built on LLVM/Clang, but it is redesigned from the ground up to solve the problems their architecture has left unsolved for years. See What is clice?

• Multi-process compilation — Compiles run in a pool of isolated worker processes, as in a modern browser. A compile that crashes or leaks on a corner case or on half-typed code costs one worker, not the server: navigation and highlighting keep working, and memory and compile priorities are managed across the pool.

  

• Modules and a shared cache — Full C++20 named module support from a compile_commands.json listing the module files: clice scans the dependencies and builds the modules needed on demand, whatever the build system or compiler, with completion, highlighting, navigation and hover on modules. PCHs and PCMs are cached on disk and reused across sessions.

  

• Compilation contexts — Non-self-contained files work out of the box: a header compiles in the context of a file including it, detected when it is opened, and you can pick another, or another compile command for a source. Build configurations group compiles, for example to switch between debug and release.

  

• Better template support — A pseudo-instantiator works out what dependent names refer to without concrete arguments, and a template instantiated once also answers through that instantiation, such as the auto parameter of a lambda passed to a ranges call. A template is a duck-typed interface and each instantiation one of its implementations: go to implementation, references and the call hierarchy on a dependent call list what each instantiation calls.

  

  

• Works out of the box — Most projects need nothing but a compile_commands.json: clice detects the environment of 50+ toolchains, nvcc, MSYS2, Cygwin and zig cc among them, and reconciles the compiler actually used with Clang, with no flags to add by hand.

The same engine answers from the command line:

• clice index builds the project's persisted index ahead of time, resumably, so an editor starts warm.
• clice lint runs clang-tidy over the project's units in a process pool and reports a shared header's findings once; with --index the same parse builds the index.
• clice format formats the files the configuration and the compilation database name, in parallel, with clang-format.
• clice command shows the command a file actually compiles with after the rules and the toolchain query, or converts a compile_commands.json into resolved -cc1 commands for other Clang tools.
• clice query reads the index on disk, no server needed, and answers in JSON: definitions, references, call graphs, type hierarchies, file dependencies.
• clice refactor rewrites the sources from the persisted index without compiling: symbol and macro renames over the whole project, or a batch of them with --spec.
• clice analyze reports the project's structure as JSON from the index, such as analyze modules: the module dependencies and cycles between directories, and the code standing in the way of modules.
• clice modularize wraps the third-party libraries a project uses as C++20 modules without touching a source file, or rewrites the project's own code into module units along analyze's split: headers become partitions, #includes become imports. clice's own modules were made with it.

• C++20 coroutines throughout, on a structured-concurrency async library built on libuv: an event loop on the main thread, over many processes and threads.
• C++20 named modules and C++23 import std, self-hosted: clice modularize generates the module wrappers of the third-party libraries, and clice serves its own codebase.
• Static reflection on templates and C++20 concepts for toml, json, bincode, blob and the command line, declared by annotations, with no boilerplate.
• Data-oriented, with almost no virtual functions beyond Clang's callback interfaces, on std::format, std::expected, std::ranges and std::views.
• A hermetic, reproducible Bazel build on the xclang toolchain, cross-compiling to every platform, ThinLTO-optimized, depending on nothing but the system libraries.

Download the latest binary from the releases page, or build from source.

Platforms: Linux (x64, ARM64), macOS (x64, ARM64), Windows (x64, ARM64)

Release channels:

The versioning rule is the VS Code Marketplace convention: even minor = stable, odd minor = pre-release. Nightly patch numbers encode the UTC build time as YYYYMMDDHH (year, month, day, hour — e.g. 2026071902 is 2026-07-19 02:00 UTC), so newer is always higher; a nightly is published only when main gained commits, and only the newest 25 nightlies, none older than 30 days, are kept, besides the one Neovim's Mason registry installs. Every published binary is the exact one that passed the full test suites — releases promote CI builds rather than rebuilding.

For the freshest bits, every green main CI run attaches installable artifacts (binaries and platform vsix) to its run page, so a fix can be tried the moment it merges (GitHub login required for artifact downloads).

Each release also ships *.symbols packages: if clice crashes, attach the newest server log to an issue and the matching symbols let us reconstruct the exact stack. The log location is printed at startup in your editor's clice output panel (Session log directory: — by default under <workspace>/.clice/logs/).

clice reads a compilation database to understand your project. For CMake:

cmake -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

By default clice loads every compile_commands.json in the project root and its immediate subdirectories (e.g. build/). See project setup for other build systems, and the configuration guide for databases elsewhere and files without one.

Full docs at docs.clice.io/clice: the guide and configuration, every language feature and command, and the design.

See building from source or join our Discord.

bazel build //:dist   # clice and the unit tests
pixi run test         # the unit tests and the cases