mcpp-language-server v0.0.2

mcpp-language-server 0.0.2

What changed

A module that does not compile, an old pinned mcpp or a stale compile database no longer leaves a
project stuck: measured on xlings with its pinned mcpp 2026.8.8.4, 0.0.1 never left preparing,
timed requests out at 10 s and kept four cores busy; 0.0.2 is ready in 8 s with no timeouts. The
findings and the plan are in .agents/docs/2026-09-22-real-project-experience.md.

Engine

• A module clangd cannot compile affects only what imports it: those files are answered at once by
  mcppls's own engine, carry one module-failed diagnostic on the import that leads there, and are
  not prepared or sent to clangd again until the failed module's own source or command changes.
  Everything else keeps clangd.
• A module that does not compile is never a reason to restart clangd, nor is a file clangd is slow
  on while it rebuilds after a change to that file or to a module it imports (the restart waits
  until that change is two minutes old and is still needed); an edit elsewhere in the project does
  not excuse it, and clangd answering nobody is contained whatever was edited. Restarts are capped
  at three in ten minutes (engine-restart-capped), and modules known to fail are not prepared
  again after one.
• Every request is answered: one a person waits for (hover, definition, completion and the like)
  waits for clangd at most 30 s in all, whether clangd is starting, the file is waiting for its
  database, or its modules are being prepared, and is then answered by mcppls's own engine. Before,
  a request queued while clangd started or while its file was held had no limit at all.
• A clangd that is stuck, not busy, is restarted within seconds: it left a request unanswered,
  answered nothing else, and used next to no CPU for five seconds. clangd 23.1 has been seen to
  hang this way after a module's source changed twice within a second, answering nothing for
  minutes; a long compile keeps a core busy and is left alone. Linux and macOS (Windows gives the
  server no process times).
• A hover that would show nothing while the modules a file imports are still being built says so,
  the way it already did while mcppls prepares them: silence reads as "there is nothing here".
• The status settles: preparation that makes no progress for a minute ends in degraded, naming
  what failed (modules-doomed, preparation-stalled), instead of preparing for good.
• clangd's own E[ lines are logged as warnings and its I[/V[/D[ chatter at debug; a module
  clangd could not build is a warning; each stand-in is named in the log with its reason.
• A request on a file clangd has not been given yet waits for it instead of being answered empty,
  and can be cancelled; a late clangd publish no longer replaces a module-failed diagnostic.

Project model

• An untrusted workspace no longer reads a compile_commands.json or build database a trusted
  session (or another build) already left on disk; it is L4 (sources only) by definition, as the
  docs always said.
• An mcpp that cannot emit build-database no longer means immediately configuring the project (or
  giving up): mcppls looks for a newer mcpp installed elsewhere on the machine and, if one advertises
  it, asks that one instead, read-only — the project still builds with the mcpp it pins. The status
  and mcppls check say "described by mcpp X (the project pins Y)".
• A compile database entry naming a file that no longer exists is dropped rather than breaking the
  model; the status notes it as stale. A module a dependency's build generates is looked for where
  builds leave it (the project's own build directory, mcpp's build-database cache) before mcppls
  falls back to an empty stand-in.
• cxxModules/status gained project.tier (spec S3-4-8, S3-4-9): which kind of source described
  the project (the README's L1..L4), independent of project.level (S1's own document-conformance
  number). The status bar and the Neovim plugin now show L<tier>, never level, which the two
  numbers sharing a range made easy to misread as the same thing.
• Scanning and a file opened while browsing no longer fold a nested project's own sources (a
  conformance fixture, a vendored copy, an example with its own mcpp.toml or CMakeLists.txt) into
  the workspace's model.
• The tier says how a model was obtained: an mcpp project described through mcpp's
  compile_commands.json is L3, not L1. A model is never replaced by one of a worse tier; the one in
  hand is kept and marked possibly stale.

Testing

• mcppls-conformance has a stress check — seeded random use (opening and switching files, hover,
  definition, references, completion, symbols) with budgets for timeouts, p90, stalls, CPU and
  memory — and client profiles (--client vscode|neovim|zed|plain).
• New fixtures: a module generated at build time (with a current, an old and a negotiated mcpp), a
  100-module chain whose base does not compile, and pinned real projects: this repository and xlings,
  as committed and with its old mcpp pin. The mock mcpp can be too old for emit build-database.
• mcpp run -p devtools -- stress runs the matrix and compares against a baseline; Neovim and the
  VS Code suite each have a stress scenario; CI runs the failing-base fixture and the stress checks
  on Linux, macOS and Windows and the generated-module fixtures on Linux and macOS (their mock mcpp
  is POSIX-only), each client profile at least once per platform, and the real projects nightly and
  before a release.
• A fixture that fails prints the last lines of the server's own log, so a failure seen only in CI
  says what the server was doing meanwhile.

Editors

• Neovim: a Lua plugin in editors/nvim (Neovim 0.10 or later) that starts mcppls for C and C++
  buffers through Neovim's own LSP client, by require('mcppls').setup() or, on 0.11 and later,
  vim.lsp.enable('mcppls'); :McpplsStatus, :McpplsRestart, :McpplsReload, a statusline
  component, and a one-time warning when clangd or ccls attaches beside it. CI runs it on Neovim
  0.10.4, 0.11.5 and 0.12.5 on Linux, and 0.10.4 and 0.12.5 on macOS and Windows.

Files

File	What it is	How to install it
mcppls-linux-x64.vsix	The VS Code extension for one platform, with that platform's payload inside it	code --install-extension <file>, or the Extensions view's “Install from VSIX…”
mcppls-darwin-arm64.vsix	The VS Code extension for one platform, with that platform's payload inside it	code --install-extension <file>, or the Extensions view's “Install from VSIX…”
mcppls-win32-x64.vsix	The VS Code extension for one platform, with that platform's payload inside it	code --install-extension <file>, or the Extensions view's “Install from VSIX…”
payload-linux-x64.tar.gz	The server, the clangd it drives and the semantic kit, as one tree. What every non-VS-Code editor needs	Unpack it and put payload/bin/ on PATH; mcppls serve speaks LSP over stdio
payload-darwin-arm64.tar.gz	The server, the clangd it drives and the semantic kit, as one tree. What every non-VS-Code editor needs	Unpack it and put payload/bin/ on PATH; mcppls serve speaks LSP over stdio
payload-win32-x64.tar.gz	The server, the clangd it drives and the semantic kit, as one tree. What every non-VS-Code editor needs	Unpack it and put payload/bin/ on PATH; mcppls serve speaks LSP over stdio
mcppls-zed-0.0.2.tar.gz	The Zed extension directory mcppls-zed/: extension.toml, the compiled extension.wasm and the crate it was compiled from, which Zed's dev-extension install compiles again. Platform-independent; the server comes from the payload	Unpack it, put the payload's payload/bin/ on PATH, then Zed's command palette: zed: install dev extension, and choose mcppls-zed (Zed compiles it, which needs Rust through rustup)
mcppls-clion-0.0.2.zip	The IntelliJ-platform plugin archive Gradle produces. Gradle and the JDK it compiles with come from the clion feature (xim:gradle, xim:jdk-temurin), so it does not depend on whatever JDK the machine happens to default to	Put the payload's payload/bin/ on PATH, then CLion: Settings → Plugins → the gear menu → Install Plugin from Disk, and restart
SHA256SUMS	sha256 of every other file in the release	sha256sum -c SHA256SUMS

Not in a release

• The Claude Code plugin: it is consumed from the repository through its marketplace file, not downloaded as an archive.
• xlings-res archives and the rendered xim-pkgindex descriptors: the ecosystem publish path is deliberately out of scope for this release, so mcppls-devtools release xlings is not run.
• The model gateway: a separate package, built and tested on its own, not part of what a user installs.

Generated from packaging/release.manifest.json for 0.0.2.

mcpp-language-server v0.0.1

mcpp-language-server 0.0.1

File	What it is	How to install it
mcppls-linux-x64.vsix	The VS Code extension for one platform, with that platform's payload inside it	code --install-extension <file>, or the Extensions view's “Install from VSIX…”
mcppls-darwin-arm64.vsix	The VS Code extension for one platform, with that platform's payload inside it	code --install-extension <file>, or the Extensions view's “Install from VSIX…”
mcppls-win32-x64.vsix	The VS Code extension for one platform, with that platform's payload inside it	code --install-extension <file>, or the Extensions view's “Install from VSIX…”
payload-linux-x64.tar.gz	The server, the clangd it drives and the semantic kit, as one tree. What every non-VS-Code editor needs	Unpack it and put payload/bin/ on PATH; mcppls serve speaks LSP over stdio
payload-darwin-arm64.tar.gz	The server, the clangd it drives and the semantic kit, as one tree. What every non-VS-Code editor needs	Unpack it and put payload/bin/ on PATH; mcppls serve speaks LSP over stdio
payload-win32-x64.tar.gz	The server, the clangd it drives and the semantic kit, as one tree. What every non-VS-Code editor needs	Unpack it and put payload/bin/ on PATH; mcppls serve speaks LSP over stdio
mcppls-zed-0.0.1.tar.gz	The Zed extension directory mcppls-zed/: extension.toml, the compiled extension.wasm and the crate it was compiled from, which Zed's dev-extension install compiles again. Platform-independent; the server comes from the payload	Unpack it, put the payload's payload/bin/ on PATH, then Zed's command palette: zed: install dev extension, and choose mcppls-zed (Zed compiles it, which needs Rust through rustup)
mcppls-clion-0.0.1.zip	The IntelliJ-platform plugin archive Gradle produces. Gradle and the JDK it compiles with come from the clion feature (xim:gradle, xim:jdk-temurin), so it does not depend on whatever JDK the machine happens to default to	Put the payload's payload/bin/ on PATH, then CLion: Settings → Plugins → the gear menu → Install Plugin from Disk, and restart
SHA256SUMS	sha256 of every other file in the release	sha256sum -c SHA256SUMS

Not in a release

• The Claude Code plugin: it is consumed from the repository through its marketplace file, not downloaded as an archive.
• xlings-res archives and the rendered xim-pkgindex descriptors: the ecosystem publish path is deliberately out of scope for this release, so mcppls-devtools release xlings is not run.
• The model gateway: a separate package, built and tested on its own, not part of what a user installs.

Generated from packaging/release.manifest.json for 0.0.1.