Upstream defects register (clangd, mcpp) #24
Description
Activity
- pinned this issue
on Sep 25, 2026 UP-01 · Module name ending in
.hangs clangd token collection-
Symptom: in an
import/moduledirective, a name ending in.with nothing but whitespace or a comment after it on that line (everyimport a.bpasses throughimport a.) sends the preprocessor into a loop (P1857 directive lexing). Linux/macOS: never finishes. Windows: exits0x80000003. Also without--experimental-modules-support. -
Affected: clangd 23.1.0. 22.1.8 and main
510126255are fine. -
Upstream: unfiled. Likely fixed on main by
6dcfc17b1b(#187846), not in 23.1.2; not bisected. -
mcppls:
WA-CLANGD-001— the text sent to clangd gets a;after the dot on the same line (positions unchanged). -
Remove when: the bundled and the oldest supported clangd finish
import a.at once (canary:conformance/fixtures/workaround-canaries). -
Evidence:
.agents/docs/2026-09-25-import-hang-status-highlight.md§1; fixturestyping-import,typing-import-spin. -
Hole (2026-09-26, measured):
WA-CLANGD-001rewrites only the text sent over LSP. Withfiles.autoSave, the file on disk holdsimport hello.; clangd resolves prerequisite modules from the file on disk (UP-14), and the file'sWorker:<file>thread then spins at 100 % CPU (buffer only: 2 ticks / 20 s; on disk: ~2000). Fixing the buffer does not stop it; only a clangd restart does. Every request for that file waits behind it, so clangd-backed completion (keywords) and hover disappear, and repeated autosaves drive restarts into the cap. Fix plan F16. -
Decision (2026-09-26): mcppls first ships the disk-side mitigation (fix plan F16: isolate the file before clangd reads the half-typed name; restart only as a fallback). Upstream work is deferred — handled later; bundling a self-built 23.1.x with the fix cherry-picked is the fallback if no backport comes.
-
Shipped (mcppls 0.0.5): the disk side is covered: a file whose text on disk has such a name is set aside before clangd builds it, a build begun on it just before is let finish for 1.5 s or clangd is restarted without it, and the file goes back once the disk is fixed (fixture
typing-autosave; hello project: 0 CPU for every clangd thread over 20 s withimport hello.on disk). -
TODO (deferred): bisect (
6dcfc17b1b?), file, ask for a 23.1.x backport. -
Root-cause correction (2026-10-07): ordinary clang parsing terminates for
the same malformed input. A raw clangd --check debugger stack stops in
TokenCollector::consume during ParsedAST construction. Controlled temporary
instrumentation identifies logical tok::eod newline: it has no spelled C++
token, so token mapping reaches a nonprogress failure path. The earlier
preprocessor-loop diagnosis and proposed main commit were hypotheses, not
established root causes. Instrumentation was removed before the repair. -
Maintained-engine repair: patch 0015 skips logical end-of-directive tokens
in collection. Local Linux raw clangd lit passes; six LSP variants reply,
recover after didChange, close/reopen and shut down. Two exact before-fix
controls time out. See engine PR Bump actions/cache from 4 to 6 #2 and tests/evidence/module-directive-recovery.json.
The syntax unit regression is added but not yet executed locally. -
Remaining: final packaged-byte and native Windows proof, cancellation
and missing-provider hangs. WA-CLANGD-001 remains enabled; no unsupported
engine loses its mitigation. The fix is not upstream-submitted yet.
-
UP-02 · Unresolved import can deadlock the unit's build
- Symptom: building a module unit whose
importresolves to nothing can deadlock clangd. - Affected: clangd 23.1.
- Upstream: unfiled.
- mcppls:
WA-CLANGD-002— such imports get an empty stand-in unit. - Remove when: clangd reports a diagnostic for such a unit instead of stalling.
- Evidence: robustness design C2, experiments S12/S17; fixture
module-faults. - Through the disk (2026-09-26): clangd reads a file's imports from disk (UP-14), so an autosave of
import hello.e(a module that does not exist yet), below a working import, stalls every request for the file — the stand-in the plan withheld while the name was typed never came. mcppls 0.0.5: the plan gives a file being edited a stand-in for every module its text on disk imports, the scanner counts an import whose;is not typed yet (as clang does), and a file whose disk imports the database clangd has read cannot resolve yet is set aside until it can (fixturetyping-autosave).
- Symptom: building a module unit whose
UP-03 · Modules a file needs are built one at a time
- Symptom: clangd builds the modules a file needs serially; cold start is slow.
- Affected: clangd 23.1.
- Upstream: unfiled (performance).
- mcppls:
WA-CLANGD-003— mcppls prepares the modules in parallel first (prime units). - Remove when: clangd builds independent modules concurrently.
- Evidence: cold-start plan 4.4; fixture
timing.
UP-04 · Finding a module's unit scans the whole database
- Symptom: to find the unit providing a module, clangd scans every file in the database, in every worker (
ProjectModules.cpp,CompileCommandsProjectModules). - Affected: clangd 23.1.
- Upstream: unfiled (performance).
- mcppls:
WA-CLANGD-004— the database names each unit (-fmodule-file=<name>=<path>,-fmodule-output=); clangd scans only that file to confirm. - Remove when: clangd looks a module's unit up without a whole-database scan.
- Evidence: usable plan W7; fixture
timing.
- Symptom: to find the unit providing a module, clangd scans every file in the database, in every worker (
UP-05 · MSVC STL aligned allocation rejected (
align_val_tambiguous)- Symptom: clangd rejects MSVC STL's aligned allocation;
align_val_tis ambiguous inside itsstdmodule. - Affected: clangd 23.1.0.
- Upstream: fixed — llvm-project#218152, in 23.1.1. clangd/clangd has published no release after 23.1.0.
- mcppls:
WA-CLANGD-005— units using MSVC STL get-fno-aligned-allocation. - Remove when: the bundled clangd is 23.1.1 or later.
- Evidence:
.agents/docs/design.md§7; fixturescmake-msvc-std,mcpp-msvc. - TODO: bump the bundled clangd once clangd/clangd releases ≥ 23.1.1.
- Symptom: clangd rejects MSVC STL's aligned allocation;
UP-06 · Stops answering one file while answering others
- Symptom: requests for one file go unanswered while others are answered.
- Affected: clangd 23.1 (experiments S2, S12).
- Upstream: unfiled.
- mcppls:
Quarantine(src/engine/clangd/guard.cppm) — the file is set aside and answered by mcppls's own engine, handed back when it changes or its term ends.
UP-07 · Stuck with no CPU after rapid module edits
- Symptom: after a module's source changes twice within a second, clangd leaves a request unanswered, answers nothing else and uses no CPU.
- Affected: clangd 23.1.
- Upstream: unfiled.
- mcppls:
StuckWatchrestarts it (docs/50-troubleshooting.md). Not detected on Windows, where clangd's CPU time is unreadable; files are set aside one by one instead.
UP-08 · Background index does not build module imports
- Symptom: a function defined in an implementation unit nobody opened resolves to its declaration only. Measured 2026-09-27: every module unit's background indexing logs
Failed to compile …, index may be incomplete(16 of 16 units of a small partitioned module;math.cppindexed with 0 symbols), and a definition whose signature uses a type from a module is indexed as a different symbol from its declaration (workspace/symbolreturns both). In mcpp's ownpreparemodule, go-to-definition onphase0_manifest_and_workspace(PrepareState&)stayed on its declaration for as long as it was measured (420 s). Opening the defining unit fixes it (the foreground builds its modules), and the symbols stay after it is closed. - Affected: clangd 23.1.0 (
BackgroundIndex::index()inclang-tools-extra/clangd/index/Background.cppbuilds the compiler instance with no ModulesBuilder). - Upstream: unfiled; the same gap is behind the symptoms of [C++20 modules] Important features still missing for the module support of clangd clangd/clangd#2569 (references and rename inside modules).
- mcppls: 0.0.5 built up to four of the module's other units, chosen by file name, and asked again. 0.0.6: WA-CLANGD-008 builds implementation units through clangd's foreground (the units of an opened file's module and its imports first, a unit changed on disk again, the rest when idle;
mcppls.index.primeImplementationUnits), the search picks the units that define the name, and a definition clangd still cannot link is found by name (plan.agents/docs/2026-09-27-qt-demo-navigation-discovery-plan.md§2.3, N-7, N-8; fixturemcpp-partition-definition, which 0.0.5 fails). - Not covered: Find References, Call Hierarchy and Rename across files that were never open.
- Remove when: clangd's background index builds the modules a unit imports before indexing it.
- Symptom: a function defined in an implementation unit nobody opened resolves to its declaration only. Measured 2026-09-27: every module unit's background indexing logs
UP-09 · No
textDocument/semanticTokens/range- Symptom: clangd has no range request for semantic tokens; advertising it made clients get "method not found".
- Affected: clangd 23.1.
- Upstream: unfiled (feature gap).
- mcppls: advertises
rangeonly when every engine can answer it (src/orchestrator/tokens.cppm).
UP-10 ·
import std;then an unprovidedexport importnever finishes- Symptom: a file where
import std;precedes anexport importof something nothing provides never finishes, when the command namesstd's unit (-fmodule-file=std=…). Minimal:export module m;import std;export import :p;. - Affected: clangd 23.1 and main
510126255. - Upstream: unfiled; to be filed with UP-01.
- mcppls: known limit, no workaround (
.agents/docs/design.md§7): only stray files outside the database get such a command; the first-diagnostics guard sets them aside after 120 s. - Evidence: import-hang plan §13 item 4.
- Symptom: a file where
UP-11 · Module scanning fails on link-phase driver errors
- Symptom: the P1689 scan (
ModuleDependencyScanner::scan→getP1689ModuleDependencyFile) runs the command as written and fails onCompilation->containsError(), while AST building (createInvocation) inserts-fsyntax-only. A driver error that only exists for a link (e.g.LTO requires -fuse-ld=lldfor windows-msvc with-fltoand no-c) fails every scan: no BMI is built, yet ASTs look fine. - Affected: clangd 23.1.0, any host (the check is per target).
- Upstream: unfiled — suggest scanning only up to the compile phase, as the AST path does.
- mcppls: the trigger was mcppls's own bug (Windows/MSVC: generated clangd compile commands with -flto but no -c break module scanning #23: engine commands lacked
-c). Fixed in 0.0.5: every engine command carries-c(fixturecompdb-lto-msvc); a scan that still fails on a command is told as an environment issue with the driver's words (fixturecompdb-rejected-command). - Evidence: Windows/MSVC: generated clangd compile commands with -flto but no -c break module scanning #23;
clang/lib/Driver/Driver.cpp(err_drv_lto_without_lld),clang/lib/Tooling/DependencyScanningTool.cpp:121; reproduced locally and in GalTranslPP CI (run 36178100611).
- Symptom: the P1689 scan (
UP-12 · Windows: Build AST crash on a module unit with unresolved imports
-
Symptom: on Windows, Build AST of a module unit whose imports cannot resolve (no BMIs) crashes,
0x80000003. Example: GalTranslPPGPPDefines.ixx(onlyexport imports and declarations). -
Affected: clangd 23.1.0 (clangd/clangd Windows release). Same input does not crash on Linux.
-
Upstream: unfiled — needs a stack and a minimal repro.
-
mcppls: triggered by UP-11; with
-cthe BMIs build and the crash is gone (--check: crash as written, exit 0 with-c). Fix plan F1, plus precise quarantine from clangd's crash context (F3). -
Evidence: GalTranslPP CI run 36178100611, experiments E3a/E3b/E3c.
-
Notes: clangd prints only
Signalled during AST worker action: Build AST,Filename:andException Code: 0x80000003; no stack, no minidump, no event-log entry. Same code as UP-01 on Windows. UTF-8 BOM is not the common factor. -
TODO: stack via the SDK's
cdb.exein that CI; compare clangd 22.1.8; reduce; file. -
Native source-qualified maintained proof (2026-10-08): Windows workflow37722679744 at engine source9e0e535191 passes the qualified nonempty original GalTranslPP case, retaining six missing BMI hints, original stdc++23/O3/g/flto flags and missing-c shape. Matching clangdSHA86468960e2a4f237f9012b3db2383ce9dd0b5d5e156dad74a3bff3f1a84539ad has PDBGUID{A440DF1E-E48C-4BB9-AC86-A1A1D219585E}/age1; debugger symbol lookup of clangdMain succeeds. Replay exits0, readers stop and actual documentSymbol result includes NameType/kind10. Engine draftPR2 tracks
tests/evidence/windows-up12-fixed-fork.jsonand qualification documentation. This proof covers that source only; final joint patches must replay the corpus again. UP13/UP20 and final native release remain unqualified.
-
UP-13 · Windows: Build AST crash on some units even with correct commands
- Symptom: on Windows, Build AST of
NormalJsonTranslator.Core.cpp(global module fragment including pybind11/toml11/proxy, thenmodule X;and severalimports) crashes,0x80000003, even with-c, working BMIs and cross-module hover. - Affected: clangd 23.1.0 (clangd/clangd Windows release). Not on Linux.
- Upstream: unfiled — needs a stack and a minimal repro.
- mcppls: containment only, shipped in 0.0.5: the file clangd names in its crash context is the one set aside (fixture
clangd-crash-context), clangd waits for the build tool's model instead of crashing on a provisional one, and a provisional model's crashes are forgotten when it is replaced. - Evidence: GalTranslPP CI run 36178100611, experiment E3d; run 36164741493.
- 0.0.8 (2026-09-30): still reproduces on GalTranslPP#1 (run 36738002085): four crashes while the provisional model serves (
NormalJsonTranslator.{Batch,Core,File}.cpp,.ixx, Build AST,0x80000003) — the files' own builds, not preparation, which 0.0.8 no longer does on a provisional model (R-4) — and five more after a partial model from mcpp (UP-M7) replaced it. mcppls 0.0.8 records each crash's exit code and the clangd binary's SHA-256 inlastExitand the incident (K-3): heredbd52c13d21ef9d284f4f0627efe76c81adf2fe0998f230127f554a54fc9dde7(clangd 23.1.0, clangd/clangd Windows release). The Windows release printsException Code:and no stack frames, so there is still no stack to report. - TODO: as UP-12; a symbolized Windows build of clangd 23.1.0 is what a stack needs.
- Symptom: on Windows, Build AST of
UP-M1 · mcpp: macOS deployment target ignored when cross-compiling
- Symptom: cross-compiling to aarch64-macos from Linux ignores
macos_deployment_target(alwaysminos 14.0); users on macOS 11–13 cannot launch the server. - Upstream: fixed — macos_deployment_target / MACOSX_DEPLOYMENT_TARGET are ignored when cross-compiling to aarch64-macos from a non-Apple host (always minos 14.0) mcpp-community/mcpp#685, mcpp 2026.9.24.1.
- mcppls: done in 0.0.5 — built with mcpp 2026.9.26.1,
macos_deployment_target = "11.0",minos 11.0verified.
- Symptom: cross-compiling to aarch64-macos from Linux ignores
16 remaining items
UP-M7 · mcpp: a module source two packages include is reported as provided twice, and the member is left out
- Symptom: on GalTranslPP,
mcpp emit build-databasefails for theGPPGUImember withMCPP_BUILD_DATABASE_PLAN_FAILED: GPPGUI: scanner errors: …\Updater\..\3rdParty\3rdModule\boost.ixx: module 'boost' is provided by package 'gpp.core' (…\GalTranslPP\..\3rdParty\3rdModule\boost.ixx) and by package 'gpp.updater' (…\Updater\..\3rdParty\3rdModule\boost.ixx)— one file, reached through two relative paths — and the rest of the workspace is described (producer-partial: 11 sets instead of 16). - Affected: mcpp 2026.9.29.4 on the 4-core Windows runner. The same mcpp and the same GalTranslPP commit described the whole workspace in run 36676829043 (2026-09-30 06:36 UTC) and did not in run 36738002085 (15:48 UTC), in the probe's own
mcpp emitstep as in mcppls's, so it is not every run. - Upstream: unfiled — the same file under two spellings should be one provider (or the packages sharing it should be told apart deliberately).
- mcppls: uses the partial answer (0.0.6); the units whose commands it lacks fail clangd's module scan, and 0.0.8 gives their modules stand-ins together (P-1) instead of one restart each. On GalTranslPP clangd then crashes on the NormalJsonTranslator units (UP-13).
- Evidence: [temporary] CI probe: mcpp-language-server on GalTranslPP (issue 23) GalTranslPP#1 runs 36738002085 (e-diag report
project.issues, the probe'smcpp emitstep) and 36676829043.
- Symptom: on GalTranslPP,
UP-21 · clangd 23.1: a unit closed while its build runs can keep a worker spinning
- Symptom: a module's importer, closed in clangd (
didClose) while its AST was being built, sometimes leaves its worker thread at a full core with nobody to answer. mcppls's containment closes the importers of a module that does not compile, at each autosave of that module. On ux-xlings three threads namedASTWorker:log.cpp(shown truncated asTWorker:log.cpp) ran at 100% with 250-330 s of CPU each. That is all of clangd's workers: every open file stayed "queued" for half an hour, and the stuck watch (next to no CPU) could not see it. Also seen asASTWorker:prebuilt.cppmon ux-mcpp. - Affected: clangd 23.1.0, Linux x64 (CI ubuntu-24.04 with 4 cores, and locally). Not observed on Windows, where mcppls cannot read per-thread CPU.
- Upstream: unfiled. No reduced case yet; it takes a module rewritten under autosave while an importer is closed mid-build.
- mcppls:
- 0.0.8 K-8 samples clangd's worker threads (Linux). A thread at a full core for 30 s on a file clangd has not reported building meanwhile restarts clangd, once per clangd, with an incident.
- K-7 restarts a clangd that keeps files queued and finishes nothing for minutes, on all platforms.
- Evidence:
- CI run 36782178214, incident
engine-busy-without-progresswith the threads above; - CI run 36787135201, incident
engine-orphan-spin; - the 0.0.8 part 2 plan (
.agents/docs/2026-10-01-0.0.8-part2-plan.md§9).
- CI run 36782178214, incident
- TODO:
- a reduced case for upstream;
- whether containment can wait for an importer's build to end before closing it.
- Symptom: a module's importer, closed in clangd (
UP-22 · clang-tidy 23.1: misc-const-correctness says a filter view can be
const- Symptom: a variable holding a view that has no const
begin()is reported as one that "can be declared 'const'" (issue False warning ofconstness #37, vulkan-rtrank_device_by_memory).- Affected views:
filter_view,drop_while_view,chunk_by_view,split_view, and any view built on one of them. - Declared
const, the code no longer compiles. g++ 16 saysno match for 'operator|' (operand types are 'const std::ranges::filter_view<...>' ...), since these views cache theirbegin().
- Affected views:
- Affected:
- clangd 23.1.0 (bundled), libstdc++ 16 and libc++ 23 alike.
- The check runs only when the user's clangd config has
Diagnostics.ClangTidy.FastCheckFilter: None, becausemisc-const-correctnessis not a fast check. - clangd 22.1.8 does not warn on a view that an adaptor returned (
auto v = r | std::views::filter(p);). It does warn on one spelled out (std::ranges::filter_view v { r, p };).
- Reduced case (std only;
.clang-tidy:Checks: "-*,misc-const-correctness"):A#include <algorithm> #include <array> #include <functional> #include <ranges> struct H { int f; unsigned long s; }; bool keep(const H& h) { return h.f == 1; } unsigned long a1(const std::array<H, 4>& in) { auto v = in | std::views::filter(keep); // 23.1: "can be declared 'const'"; 22.1.8: nothing return std::ranges::fold_left(v | std::views::transform(&H::s), 0UL, std::plus()); }
transform_viewover an array is reported too, and correctly:constcompiles there. - Upstream: unfiled. The reduced case above is ready for llvm-project (clang-tidy, ExprMutationAnalyzer).
- mcppls: WA-CLANGD-010 (0.0.9) drops a
misc-const-correctnessdiagnostic whose type, taken from the canonicalakatype when clangd gives one, is a std::ranges view that has one of those four views on its base chain.ref_viewstops the walk.lazy_split_viewand every other type are kept.
- Evidence:
.agents/docs/reviews/2026-10-01-issue-37-review.md§A;tests/test_workarounds.cpp. - TODO:
- file upstream;
- remove WA-CLANGD-010 once the bundled clangd no longer warns on the case above.
- Symptom: a variable holding a view that has no const
UP-23 · clangd 23.1: with
--experimental-modules-support, every completion scans the file's module dependencies again- Symptom: on a project with no modules but heavy headers (vulkan-hpp, issue False warning of
constness #37), completion is about 3 times slower with the flag than without it.-
Measured on 12 completions (
phy_device.,vk::,memory_properties.,std::ranges::), median and worst:median worst without the flag 82 ms 95 ms with the flag 254 ms 869 ms header, without / with the flag 81 ms / 257 ms — -
The other mcppls flags (
--use-dirty-headers,--header-insertion=never,-j=8) change nothing. -
With the flag, clangd's verbose log shows one more driver invocation per completion: 25 against 13 for the same session. That is a dependency scan, which preprocesses the whole translation unit, vulkan.hpp included, on every request.
-
- Affected: clangd 23.1.0 (bundled), Linux x64; any file with a large preamble.
- Upstream: unfiled (performance). clangd could keep a file's module dependency scan with its preamble instead of repeating it per request.
- mcppls: WA-CLANGD-009 (0.0.9) starts clangd without
--experimental-modules-supportfor a project whose plan has no module unit, no module import, no standard library module and no stand-in.- The decision is kept per workspace, so the next session starts right away.
- A first plan that disagrees restarts clangd before any document reaches it.
- The first plan that uses modules (an import typed into such a project) restarts clangd with the flag for the rest of the session.
- Result on the same file through mcppls: median 259 ms (0.0.8) → 97 ms.
- Evidence:
.agents/docs/reviews/2026-10-01-issue-37-review.md§B (bench script and numbers). - TODO:
- file upstream with a reduced project;
- a non-module, heavy-header UX fixture with a completion budget against plain clangd.
- Symptom: on a project with no modules but heavy headers (vulkan-hpp, issue False warning of
UP-24 · [clangd] a copy-on-read BMI is left behind whenever clangd dies before releasing it, and the only GC waits three days (by atime)
Labels:
clangd,clang:modulesSymptom. When clangd reuses a published BMI it first copies it to a timestamped sibling
(<module>-YYYYMMDD-HHMMSS-<serial>.pcm) and hands that copy to clang; the copy is removed only in the owner's
destructor (ModulesBuilder.cpp23.1.0 §198-209, §437-461). A clangd that is killed by a crash never runs it, so
the copy stays. One real workspace (Windows 11, MSVC STL, 23.1.0) after 26.5 h: 64.36 GiB, 6837.pcmfor 48
module units, where one file per unit×command directory is 2.03 GB (2.9%) — 97.1% leftovers, up to 127
copies in one directory, 219 retained "clangd exited unexpectedly" lines (≈305 MB leaked per crash). Three sampled
copies ofpybind11were byte-identical (39,639,212 bytes; SHA-2565d0b9efe…9289ab) with distinct ids — copies,
not rebuilds, and not hard links.Affected. 23.1.0 (persistent cache + copy-on-read + the 3-day atime GC). 22.x uses a per-process temp layout.
Upstream status.
unfiledhere (mcppls does not file; recorded in the mcppls register). The GC exists
(llvm/llvm-project#193973, merged to main 2026-04-24) and is the intended answer, but: (1) a crash leaks and the
window is 259200 s, so peak ≈ leak rate × 3 days; (2) it readsst_atime— the PR body notes atime is unreliable
on some systems, and NTFS last-access updates are off by default, so a copy still mapped by a live clangd can be
selected and the removal fails with a sharing violation (only logged); (3) the option's description says "versioned
copy-on-read module files" whilecollectModuleFiles()takes every.pcmunder the cache root, so lowering the
threshold also deletes published BMIs (the cost becomes rebuilding 30–40 MB modules, not re-copying them).What mcppls does (workaround).
WA-CLANGD-011. mcppls owns<cdb>/.cache/clangd(it already clears.locks
there before clangd starts, RD12) and extends that to the copies: before each clangd start, and for every workspace
no instance has open, it removes files whose name parses as the versioned shape, keeping the published
<module>.pcm, in the background and only for files older than the new generation's start; it also enforces a
size budget per workspace (4 GiB) and in all (16 GiB), reclaims orphaned per-instance cache directories, and shows
the whole thing in the editor status bar with a one-click sweep. Design: PR #39 /
.agents/docs/2026-10-02-cache-growth-root-fix-plan.md(C-7, C-8, C-9, C-13). mcppls deliberately does not lower
--modules-builder-versioned-gc-threshold-secondsby default (point 3).When that can go. When the bundled clangd leaves no copy-on-read file behind after a process dies, or removes an
earlier clangd's leftovers of the same cache root within minutes without touching the published BMI. Canary:
conformance/fixtures/cache-budget+tests/test_cache.cpp— the sweep's semantics are asserted on every run;
a real-crash canary needs the crash-symbol work of the 0.0.7 plan (T15/K-3).Evidence.
mcppls-cache-20261002-222834.zip+.agents/reviews/mcppls-cache-20261002-cause-analysis.md;
ModulesBuilder.cppofllvmorg-23.1.0§40-44/§198-209/§437-461/§986-1018; #193973.TODO. [x] post this comment and add its row to #24's index
[x] put the link inWA-CLANGD-011.upstream
[ ] attach a minimal reproduction once the crash-symbol work of the 0.0.7 plan (T15/K-3) lands.- added a commit that references this issue
on Oct 3, 2026 UP-25 · clangd 23.1: every completion on a file that imports modules costs about a second, even on an unchanged document
Labels:
clangd,clang:modules-
Symptom: a project that uses modules (qt-demo: Qt 6.11 headers,
import std;+import nlohmann.json;, gcc 16 / libstdc++, the mcppls-generated CDB); the bundled clangd 23.1.0 driven directly over stdio, mcppls out of the picture — these numbers are clangd's alone. Keystroke replay at the importer (nlohmann::j, thennlohmann::js), three rounds, plus re-asks on an unchanged document:request latency result after typing j(3 rounds)981–1043 ms 22 items, jsonpresentafter typing s(3 rounds)979–998 ms 4 items, correct no edit, re-ask (3 rounds) 950–969 ms the same 4 items - Position does not matter:
cli.(a Qt member) and a plain word in the same importing file: 977–1033 ms. - Control:
moc_counter.cpp, same project, same CDB, same flags (--experimental-modules-supportincluded), no module imports: 60–65 ms for the same replay — 16×. - First diagnostics after open: 2.2 s (the importer) vs 1.1 s (the control).
- The BMIs are built and persistent (
std.pcm35 MB andnlohmann.json.pcm25 MB under<cdb>/.cache/clangd/modules, "Reusing persistent module …" in the log), so the cost is not building them: each AST build re-loads the module context ("Built prerequisite modules … in 0.53 s"), and the importer's preamble is 254 KB built in 0.01 s — the imports are not in it, so nothing between requests amortizes the module state. Typing bursts cancel each request before it finishes, which reads in the editor as "completion does not come up".
- Position does not matter:
-
Affected: clangd 23.1.0 (bundled), Linux x64; any file that imports modules whose BMIs are already built and cached. Distinct from UP-23: that one is the flag's cost on a project without modules; this one is the cost on a file that actually imports, with everything already built.
-
Upstream: unfiled (performance). A completion on an unchanged document should reuse the module context of the cached AST; an importing file's preamble cannot carry the imports, but the per-request BMI re-load looks avoidable.
-
mcppls: WA-CLANGD-012 (0.0.11, PR 0.0.11: the completion budget follows the file, so clangd's ~1 s module-importer answers are not cancelled (UP-25) #41). The flat completion budget stays 1000 ms; the workspace records each core-engine completion answer per file and its latency (the late answers C-2 keeps included), and where two answers in the last ten seconds have all landed past the flat budget, that file's completion and signature-help budget extends to their slowest plus 500 ms, 2.5 s at most — the importer's ~1 s answers arrive instead of being cancelled at the line. An engine that answers rarely (a broken module rebuilding, a fan-out save) or quickly keeps the flat budget, and the fallback with it. A flat 1.5 s budget was tried first and the UX gate rejected it with data (U16-module-autosave: 93 completions p95 1.50 s, every one riding to the budget; ux-xlings and ux-mcpp failed, CI run 37188779178) — a flat constant cannot hold both regimes.
-
Evidence: LSP replay probe against the bundled clangd with the workspace CDB (2026-10-04); clangd verbose log (preamble size and time, "Reusing persistent module", "Built prerequisite modules", one "ASTWorker building file … version N" per keystroke).
-
TODO:
- file upstream with a reduced project (one interface unit + one importer; the replay script is ready);
- the mcppls-side mitigation: WA-CLANGD-012 (above), in 0.0.11 (PR 0.0.11: the completion budget follows the file, so clangd's ~1 s module-importer answers are not cancelled (UP-25) #41).
-
- added a commit that references this issue
on Oct 4, 2026 UP-O1 · openkal-macos 0.12.0 can terminate a pipe writer with SIGPIPE
- Symptom: native Intel macOS execution of the product's dev and release test_process binaries dies with signal 13 when the peer of a blocked pipe write is stopped. A closed-peer write should return an error and leave the parent alive. Source env.cpp explicitly records the unhandled SIGPIPE limitation.
- Affected: openkal-macos 0.12.0 used by this candidate; the same limitation is documented in 0.11.0. Actual reproduction here is darwin-x64, not a claim about all macOS releases.
- Upstream: unfiled. This is the openkal backend/runtime boundary, not a clangd defect.
- mcppls: proposed platform compensation WA-PLATFORM-001 protects each owned child-input pipe with Darwin F_SETNOSIGPIPE before spawning. It fails channel creation if protection cannot be installed. It does not change global signal policy or pretend the C ABI can install a Darwin signal handler. Native fixed-byte CI is still pending.
- Remove when: the selected openkal-macos release guarantees closed pipe writes return an error on both promised macOS architectures, under a parent with default SIGPIPE disposition; verify the regression canary before removal.
- Evidence: product CI run 37552260398, jobs 112572688643 (dev) and 112572688644 (release), both SIGPIPE in test_process. .agents/docs/2026-10-07-darwin-pipe-write.md; tests/test_process.cpp's blocked-peer shutdown and closed-peer write canaries. Apple's xnu/bsd/sys/fcntl.h defines F_SETNOSIGPIPE and its EPIPE behavior.
- TODO: obtain native fixed-byte results on Intel and arm64; upstream reduced reproduction; keep this entry open until those results exist.
UP-V1 · vscode-languageclient loses initialization ownership when its server exits during startup
Affected: vscode-languageclient 10.1.1 (the extension lockfile); reproduced with VS Code 1.132.0 on Linux. Product CI run 37658653689 on Intel macOS also reports duplicate
clangd.applyFix, disposed pending responses andUnexpected SIGPIPEduring the crash-loop test, but this entry does not claim that SIGPIPE has the same root cause.Symptom and evidence: SIGKILL the replacement server while client initialization is pending. With the original extension and the new real-payload regression, the suite produces 1 passing / 2 failing tests and captures four unhandled rejections: two pending responses disposed, two stop attempts on a Starting client. The guarded lifecycle produces 2 passing tests and zero captured unhandled rejections, and verifies command registration plus a cache request after recovery. Detailed proof, intermediate failures and limits:
.agents/docs/2026-10-08-client-crash-recovery.mdin draft PR #46.Source:
vscode-languageclient/lib/common/client.js10.1.1:start()owns a separate internal_onStartpromise;handleConnectionClosed()disposes the connection and resets it before the original initialization continuation necessarily settles;doInitialize()callsvoid stop()on failure, which rejects for a dead Starting client. Same-client automatic restart can additionally overlap feature cleanup/initialization. The macOS duplicate-command explanation is source-supported inference, not the exact stack reproduced on Linux.Upstream status: unfiled. A standalone library reproducer and upstream review remain TODO; no upstream fix is known or claimed by this entry.
mcppls: WA-VSCODE-003 in
editors/vscode/src/workarounds.tsandextension.ts. Wait for original startup settlement in the close handler before library cleanup/reset; absorb a failed shutdown only after that client's transport closes. The extension queues fresh-client recovery, preserves the three-crash budget, and skips conflict-detection prompts during automatic recovery.Remove when: an updated upstream library passes the initialization SIGKILL test with the guards removed: no orphaned start promise, no unhandled shutdown rejection, working command registration and requests after recovery.
test/suite/zCrashLoop.test.tsis the behavioral regression; run the unguarded negative control when evaluating a dependency upgrade.TODO: standalone reproducer, upstream filing, inspect any upstream lifecycle fix before removing WA-VSCODE-003, rerun the native Intel macOS VSIX scenario and separately establish the SIGPIPE cause.
UP-V2 · vscode-jsonrpc leaves a failed request write's async executor rejection unowned
Affected: vscode-jsonrpc 9.0.2, used by vscode-languageclient 10.1.1 in the extension lockfile. Reproduced on Linux with the actual dependency and a destroyed Node stream. Product CI run 37686772481 reports two unhandled
ERR_STREAM_DESTROYEDrejections in the Intel macOS VSIX crash-loop suite after the UP-V1 lifecycle guard was present.Symptom and evidence: A correctly caught
sendRequest()still emits an independent unhandled rejection when its stream write fails. The caller receivesMessageWriteError(-32099), while the process separately receivesERR_STREAM_DESTROYED. Source:vscode-jsonrpc/lib/common/connection.js,sendRequest()lines 1124–1151: an async Promise executor awaits the write, rejects the caller in its catch, then throws the same error into the executor's discarded promise. The CI stack starts in Node_write, thenWritableStreamWrapper.write,StreamMessageWriter.doWrite; the crash-loop after-all assertion catches two orphaned rejections. This source defect is directly reproduced; the CI stack alone does not identify each original request.Upstream status: unfiled. A standalone upstream issue and dependency upgrade evaluation remain TODO.
mcppls: WA-VSCODE-004, a writer scoped to each LanguageClient transport. A failed write invalidates that protocol stream and raises connection closure; normal connection disposal rejects outstanding requests. The wrapper owns the failed write promise rather than allowing the library's discarded executor to throw. There is no process-wide rejection handler in production. Live responses and server request errors remain unchanged. A deterministic Linux regression receives the normal disposed-request error (-32097), observes no orphaned rejection, and checks a live response plus a real server error.
Remove when: a dependency upgrade passes the failed-stdio-write regression without the writer wrapper: the request rejects once, no independent unhandled rejection, normal responses and server errors still work.
editors/vscode/test/unit/transportWriter.test.tsand the real-payloadtest/suite/zCrashLoop.test.tscover those behaviors. Native Intel macOS revalidation remains required; Linux controlled evidence is not a native verdict.TODO: standalone upstream filing, rerun the native Intel macOS VSIX crash-loop suite, inspect the upstream sendRequest implementation before retiring WA-VSCODE-004.
UP-26 — asynchronous preamble trace metadata outlives its filename
Symptom:
BuildPreambletraceargs.Filecontains freed-looking bytes and can make the trace JSON invalid UTF-8. This is observed diagnostic corruption; it is not evidence of a semantic compiler crash.Affected: the pinned LLVM/clangd 23.1.0 baseline borrows
FileNameatPreamble.cpp'sBuildPreambleandCreatePreamblePatchspans.json::Value(StringRef)retains borrowed storage, whileJSONSpancan remain alive through a retained requestContextafter the lexical span and filename owner end. Other upstream versions are untested.Upstream status: unfiled; deterministic old/fixed Linux regression is complete; native/full-recipe qualification remains pending.
What mcppls does: maintained-engine patch 0051 owns the filename string at those two trace callsites. No server/extension workaround or semantic assertion suppression. Patch 0048's matched Qt probe retained an invalid trace at byte 182878; its structured semantic report remains valid. The original corrupt trace is retained byte for byte. The actual preamble callback canary retains Context beyond buildPreamble, overwrites the caller filename with same-length ASCII x, and proves that old production emits x while fixed production preserves the exact original path.
Removal condition: upstream owns the metadata for its complete event lifetime and the delayed-context canary passes on the bundled base.
Evidence / TODO: engine draft PR #2; owned trace patch and proof; the same test object fails against old production and three focused fixed tests pass22ms. Final raw Qt trace passes strict UTF8/JSON and seven actual filename values, with all four semantic requests passing. Private changed-object links do not qualify native clean recipes. TODO: native canaries and upstream minimal report. This row remains open pending those checks.
UP-27 · clangd23.1: a default OverlayCDB command mangler is called unconditionally during module scanning
- Symptom: the public
OverlayCDB(&Base)constructor defaults itsCommandManglerto null.OverlayCDB::getProjectModulesnevertheless installs a nonempty callback that unconditionally calls that null mangler. A real required-module scan through this default overlay segfaults at address0; ordinarygetCompileCommandalready guards the same optional mangler. - Affected: confirmed source in the unmodified pinned
llvmorg-23.1.0source archive; Linux x64 actual private integration control with real CDB and external module provider. This is an API default/null boundary, not a crash claim about the normal ClangdMain path, which supplies a mangler. - Upstream: unfiled. The original source callback in GlobalCompilationDatabase.cpp lines858–861 has no guard; the documented constructor default is null. Newer versions are not verified.
- mcppls: no product workaround or WA ID added. A separate maintained-engine patch0058 will guard the optional call while preserving nonempty command configuration and request-generation behavior. Registration precedes implementation/export.
- Evidence: actual default-overlay control fails with SIGSEGV; GDB shows #0 null PC, Bump actions/upload-artifact from 4 to 7 #1 getCompileCommandForFile, Bump actions/cache from 4 to 6 #2 ModuleDependencyScanner::scan, Bump actions/setup-node from 4 to 7 #3 CompoundProjectModules::getRequiredModules. Raw private evidence
/tmp/mcppls-provider57-build/external-gdb.log; pinned original source extracted readonly as/tmp/mcppls-pinned-GlobalCompilationDatabase.cpp. A production-style explicit noop callback passes but cannot replace the default/null regression. - TODO/drop: prove the actual default overlay scans and imports a real compiled module, and explicit command overrides/manglers still win; same-object negative/positive control; native CI; file upstream and drop when the optional-mangler guard and equivalent canary land. No speculative editor exposure, source-wide ABI or release qualification claim.
- Symptom: the public
UP-28 · Header-import preambles lose module visibility; avoiding every module preamble reparses heavy textual headers
- Symptom: A header that imports a C++ module can produce missing module visibility through a PCH. Disabling the preamble for every importing translation unit preserves that safety boundary but repeatedly reparses large textual prefixes during completion.
- Affected scope: LLVM's experimental C++ modules path; upstream llvm-project#181770. The maintained pinned 23.1.0 joint tree retains conservative preamble skipping when module dependencies are attached. This is distinct from UP-23's repeated dependency scanning.
- Upstream: [clangd] import from #include not working llvm/llvm-project#181770 ; [clangd] Introduce --skip-preamble-build command line option llvm/llvm-project#189284 (merged mitigation). Earlier proposal [clangd] [C++ Modules] Skip PCH when TU imports modules llvm/llvm-project#187432 was not merged. The separate ModuleCache lifetime fix in llvm-project#203952 is already present in the pinned source and is not claimed as an unfixed defect here.
- mcppls: No new product workaround. Maintained candidate0066 allows only a verified import-free textual prefix, preserving full original TU commands and module read leases. Header imports, unknown scans, compiler module maps and explicit PCH inputs keep conservative handling. Exact filesystem replay correction0065 supports provenance verification.
- Evidence: Correct-path Qt JSON completion with0061/0062 spends about847ms in semantic completion. Private0066 initial original-command JSON qualified/member controls returned required semantics and all8 inserted results compiled with the actual GCC command; observed warm requests43–51ms and edited123–131ms. These small concurrent exploratory controls do not qualify latency distributions or the release improvement gate.
- Removal/drop: Drop candidate0066 if canonical scan, exact content/filesystem provenance or emitted PCH import audit cannot establish the prefix is import-free. Reassess against an upstream implementation that safely preserves module visibility through preambles; never relax compiler validation to meet timing.
- TODO: Final focused controls, actual compiler insertion proof, independent3×30 quiet distributions and matched correct-path baseline, native whole-recipe validation. Header-import crash/visibility cases remain separate canaries.
UP-29 · GNU standard-module producer flags enable Clang implicit builtin maps during scanning
- Symptom: The original GNU libstdc++16.1 bits/std.cc provider is compiled by canonical GCC g++ with -std=c++23 -fmodules, includes and sysroot, without a module mapper. The maintained clangd path interprets -fmodules as enabling Clang implicit module maps; its builtin _Builtin_inttypes enters resource inttypes.h with unknown intmax_t/uintmax_t in this actual project. Actual std-qualified completion remains unqualified.
- Affected scope: Pinned clangd23.1.0/GNU16.1 standard-module provider commands in the original Qt CDB. Ordinary GNU source and explicit Clang module-map configurations are separate cases. This is a missing command-dialect adaptation, not proof that every GNU standard-library version is supported by Clang.
- Upstream: unfiled; current source/canonical-command evidence available. No upstream fixed-version claim.
- mcppls: No product workaround added. Existing maintained0061 translates only canonical GCC commands carrying a nonempty GNU module-mapper marker, preserving -fmodules and explicit Clang options. That guard deliberately leaves this real standard-library producer unchanged. Candidate0067 will investigate same-install canonical GNU std/std.compat source provenance and bounded actual named-module role; unknown/failed/outside-install/non-C++/header-unit recognition must decline. No global all-GCC flag removal.
- Evidence: Original /home/speak/test/mcpp/qt-demo/compile_commands.json provider uses same GCC installation include/c++/16.1.0/bits/std.cc, source global module fragment and export module std. Actual scanner records the builtin inttypes failure. Previous broad private translation experiment is only causality evidence, not a qualified fix. Product/compiler-generated commands are preserved as inputs.
- Removal/drop: Drop scoped adapter if role/provenance cannot be established or explicit Clang configuration is changed. Remove when upstream command handling distinguishes GNU named-module producer intent and all original-command semantic/compiler controls pass.
- TODO: Source/command negatives, exact original scan and worker command validation, real std-qualified Sema/typed candidates and actual GCC insertion compilation, full context distributions and native joint recipe. Candidate0067 is private and unqualified.
Register of upstream defects mcppls depends on. This body is the index; each comment below is one problem.
Bundled: clangd 23.1.0 (clangd/clangd release). Code workarounds:
src/engine/clangd/workarounds.cpp(WA-CLANGD-<n>, listed bymcppls report); deliberate limits:.agents/docs/design.md§7.Rules: a new problem gets a comment and a row here; adding or removing a workaround updates its comment; link upstream issues/fixes when they exist; walk this list before bumping the bundled clangd.
clangd / LLVM
.hangs the preprocessor (crashes on Windows)align_val_tambiguous)textDocument/semanticTokens/rangeimport std;then an unprovidedexport importnever finishes-c)-c; crash file set aside (0.0.5);afterimportis reported on the next lineprepare_build)mcppls cache --prune(0.0.7)mcpp.manifest.typesconst(issue #37)--experimental-modules-supportrescans module dependencies on every completion (~3x slower on heavy headers, issue #37)| UP-26 | Preamble trace filename metadata can outlive borrowed storage and corrupt trace JSON | unfiled; pinned 23.1.0 source-backed | proposed maintained patch0051 owns metadata; delayed-context/native canaries pending |
| UP-27 | Default OverlayCDB invokes a null command mangler during module scanning | unfiled; 23.1.0 source/API control confirmed | maintained engine0058 pending; no product workaround |
| UP-28 | Header-import PCH visibility guard reparses heavy textual prefixes | llvm-project#181770; mitigation#189284 | conservative handling retained; verified import-free prefix candidate0066 pending |
| UP-29 | GNU std producer flags enable Clang implicit builtin maps during scanning | unfiled; pinned23.1.0/GNU16.1 source evidence | scoped same-install standard-producer adapter candidate0067 pending |
mcpp
emit build-databasefails whole on one member's failuretarget/read; missing reported (0.0.6)workspace = truein a path-dependency member failsemit build-databasetakes about a minute on a large workspacePRoot (Termux)
execveatwith a directory descriptor fails with ENOSYSexecve(0.0.7)openkal
VS Code / languageclient