mcpp-language-server v0.0.13

mcpp-language-server 0.0.13

What changed

The bundled engine is mcppls-clangd 0.0.14
(23.1.0-mcppls.2): 29 patches, four of them new. This release is about seeing what happens, opening a project
again quickly, and editing without one failure taking the rest down.

Completion and modules

• Completion answers while modules are still being built. In a file that imports modules, completion
  waits for the file's first preamble at most 600 ms and for a module the file newly imports at most 250 ms.
  Past that it answers with what there is, marked incomplete, so the editor asks again as you type and the
  imported names come once they are built. Completion used to wait for every missing module: minutes on a
  large Windows project while its modules were prepared.
• One module that does not compile leaves the others (#47). The files importing it keep every other
  module, std included; the import of the failed module says module M did not compile: <its first error>,
  and the error is in the default log too. The module is tried again once its source changes. With an older
  engine, its importers are answered by mcppls's own engine as before (WA-CLANGD-014).
• Typing in a module unit keeps completion fast. clangd scanned a module unit whole on every keystroke and
  every completion, its global module fragment's headers (<windows.h>, Qt) preprocessed again each time; it
  now keeps the scan while the body is typed in. On Windows, completion in a module unit being typed into, with a
  file importing it open, had come up to mcppls's one-second deadline.
• A file typed into without a pause is not taken for one clangd will not finish (#53). clangd builds such a
  file version after version under one "parsing" status; each version is now timed on its own, and a build that
  really never ends is still found.

build.mcpp

• A build program that does not compile leaves the project its complete description. A half-typed
  build.mcpp, or one mcpp fails to compile or run for a reason of its own, no longer takes the targets' flags
  and generated units away. The state stays ready with a build-program-failed notice, mcpp's error is a
  diagnostic on build.mcpp at its line, and clangd is not restarted. The next complete description is taken.
• A changed build.mcpp is applied once it is saved, left alone for two seconds, and compiles in the
  editor. Describing the project compiles and runs the build program; a run for every autosave was the
  cost. The status says build-program-held while it waits. New setting mcppls.buildProgram.apply
  (auto, or manual with C++ Modules: Apply build.mcpp, mcppls.applyBuildProgram).
• An include the build has not generated yet says so: build once (Build in Terminal) and it has its
  semantics.

Opening a project again

• A checkout keeps the cached model. The model cache records each input's content: a branch switch or a
  restored file that rewrites the build description with its own bytes leaves the cache fresh, where every
  warm start of a large Windows project began "older than its inputs" after one. When an input did change,
  the log names it.
• Together with the kept description above, a warm start no longer describes the project differently from
  the session before when mcpp fails midway, which made its modules be built again under other commands.

Seeing what happens

• Versions in the overview. The status and the report carry about: the server, the editor package, the
  engine and how often it was restarted, the kit and the mcpp in use, with no paths (S3-4-31). VS Code's hub
  opens with them (click to copy) and the running state. An editor package that started a server other than
  its own is called out (version-mismatch).
• A default log says why. One line per start says what it cost (model, engine, first diagnostics, first
  completion, modules built and why, restarts, ready); the report keeps the last five starts. mcppls-clangd
  says why each module is rebuilt and what each file's modules cost; every ten minutes of use a health line
  sums up requests and the engine. clangd's command echo after every file build is kept at debug, and its
  errors are limited apart from its chatter. Restarts say whether they count against clangd. A turn of the
  timers that holds the event loop says which part held it. docs/50-troubleshooting.md lists the lines.
• Watched-file changes that are not files no longer make clangd refuse the whole notification (#53).
• The mcpp version is kept with mcpp's answer, so every describe reports it.

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-linux-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-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-linux-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-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.13.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.13.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.13.