Upstream defects register (clangd, mcpp) #24

Activity

1. Sunrisepeak

   pinned this issue on Sep 25, 2026
2. Sunrisepeak commented on Sep 25, 2026

   

   Sunrisepeak

   on Sep 25, 2026

   Last edited by Sunrisepeak

   OwnerAuthor

   More actions

   UP-01 · Module name ending in . hangs clangd token collection

   • Symptom: in an import/module directive, a name ending in . with nothing but whitespace or a comment after it on that line (every import a.b passes through import a.) sends the preprocessor into a loop (P1857 directive lexing). Linux/macOS: never finishes. Windows: exits 0x80000003. Also without --experimental-modules-support.

   • Affected: clangd 23.1.0. 22.1.8 and main 510126255 are 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; fixtures typing-import, typing-import-spin.

   • Hole (2026-09-26, measured): WA-CLANGD-001 rewrites only the text sent over LSP. With files.autoSave, the file on disk holds import hello.; clangd resolves prerequisite modules from the file on disk (UP-14), and the file's Worker:<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 with import 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.
3. Sunrisepeak commented on Sep 25, 2026

   

   Sunrisepeak

   on Sep 25, 2026

   Last edited by Sunrisepeak

   OwnerAuthor

   More actions

   UP-02 · Unresolved import can deadlock the unit's build

   • Symptom: building a module unit whose import resolves 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 (fixture typing-autosave).
4. Sunrisepeak commented on Sep 25, 2026

   

   Sunrisepeak

   on Sep 25, 2026

   OwnerAuthor

   More actions

   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.
5. Sunrisepeak commented on Sep 25, 2026

   

   Sunrisepeak

   on Sep 25, 2026

   OwnerAuthor

   More actions

   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.
6. Sunrisepeak commented on Sep 25, 2026

   

   Sunrisepeak

   on Sep 25, 2026

   OwnerAuthor

   More actions

   UP-05 · MSVC STL aligned allocation rejected (align_val_t ambiguous)

   • Symptom: clangd rejects MSVC STL's aligned allocation; align_val_t is ambiguous inside its std module.
   • 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; fixtures cmake-msvc-std, mcpp-msvc.
   • TODO: bump the bundled clangd once clangd/clangd releases ≥ 23.1.1.
7. Sunrisepeak commented on Sep 25, 2026

   

   Sunrisepeak

   on Sep 25, 2026

   OwnerAuthor

   More actions

   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.
8. Sunrisepeak commented on Sep 25, 2026

   

   Sunrisepeak

   on Sep 25, 2026

   OwnerAuthor

   More actions

   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: StuckWatch restarts it (docs/50-troubleshooting.md). Not detected on Windows, where clangd's CPU time is unreadable; files are set aside one by one instead.
9. Sunrisepeak commented on Sep 25, 2026

   

   Sunrisepeak

   on Sep 25, 2026

   Last edited by Sunrisepeak

   OwnerAuthor

   More actions

   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.cpp indexed with 0 symbols), and a definition whose signature uses a type from a module is indexed as a different symbol from its declaration (workspace/symbol returns both). In mcpp's own prepare module, go-to-definition on phase0_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() in clang-tools-extra/clangd/index/Background.cpp builds 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; fixture mcpp-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.
10. Sunrisepeak commented on Sep 25, 2026

    

    Sunrisepeak

    on Sep 25, 2026

    OwnerAuthor

    More actions

    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 range only when every engine can answer it (src/orchestrator/tokens.cppm).
11. Sunrisepeak commented on Sep 25, 2026

    

    Sunrisepeak

    on Sep 25, 2026

    OwnerAuthor

    More actions

    UP-10 · import std; then an unprovided export import never finishes

    • Symptom: a file where import std; precedes an export import of something nothing provides never finishes, when the command names std'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.
12. Sunrisepeak commented on Sep 25, 2026

    

    Sunrisepeak

    on Sep 25, 2026

    Last edited by Sunrisepeak

    OwnerAuthor

    More actions

    UP-11 · Module scanning fails on link-phase driver errors

    • Symptom: the P1689 scan (ModuleDependencyScanner::scan → getP1689ModuleDependencyFile) runs the command as written and fails on Compilation->containsError(), while AST building (createInvocation) inserts -fsyntax-only. A driver error that only exists for a link (e.g. LTO requires -fuse-ld=lld for windows-msvc with -flto and 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 (fixture compdb-lto-msvc); a scan that still fails on a command is told as an environment issue with the driver's words (fixture compdb-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).
13. Sunrisepeak commented on Sep 25, 2026

    

    Sunrisepeak

    on Sep 25, 2026

    Last edited by Sunrisepeak

    OwnerAuthor

    More actions

    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: GalTranslPP GPPDefines.ixx (only export 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 -c the 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: and Exception 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.exe in 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.json and qualification documentation. This proof covers that source only; final joint patches must replay the corpus again. UP13/UP20 and final native release remain unqualified.
14. Sunrisepeak commented on Sep 25, 2026

    

    Sunrisepeak

    on Sep 25, 2026

    Last edited by Sunrisepeak

    OwnerAuthor

    More actions

    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, then module X; and several imports) 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 in lastExit and the incident (K-3): here dbd52c13d21ef9d284f4f0627efe76c81adf2fe0998f230127f554a54fc9dde7 (clangd 23.1.0, clangd/clangd Windows release). The Windows release prints Exception 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.
15. Sunrisepeak commented on Sep 25, 2026

    

    Sunrisepeak

    on Sep 25, 2026

    Last edited by Sunrisepeak

    OwnerAuthor

    More actions

    UP-M1 · mcpp: macOS deployment target ignored when cross-compiling

    • Symptom: cross-compiling to aarch64-macos from Linux ignores macos_deployment_target (always minos 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.0 verified.
16. 19 remaining items

    Load more

17. Sunrisepeak commented on Oct 1, 2026

    

    Sunrisepeak

    on Oct 1, 2026

    OwnerAuthor

    More actions

    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-support for 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.
18. Sunrisepeak commented on Oct 2, 2026

    

    Sunrisepeak

    on Oct 2, 2026

    OwnerAuthor

    More actions

    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:modules

    Symptom. 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.cpp 23.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 .pcm for 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 of pybind11 were byte-identical (39,639,212 bytes; SHA-256 5d0b9efe…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. unfiled here (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 reads st_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" while collectModuleFiles() takes every .pcm under 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-seconds by 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.cpp of llvmorg-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 in WA-CLANGD-011.upstream
    [ ] attach a minimal reproduction once the crash-symbol work of the 0.0.7 plan (T15/K-3) lands.
19. Sunrisepeak

    added a commit that references this issue on Oct 3, 2026

    mcpp-language-server 0.0.10: the module cache is bounded, visible, an…

    ...

    eaf9ea4
20. Sunrisepeak commented on Oct 3, 2026

    

    Sunrisepeak

    on Oct 3, 2026

    Last edited by Sunrisepeak

    OwnerAuthor

    More actions

    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, then nlohmann::js), three rounds, plus re-asks on an unchanged document:

      request	latency	result
      after typing j (3 rounds)	981–1043 ms	22 items, json present
      after 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-support included), 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.pcm 35 MB and nlohmann.json.pcm 25 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".

    • 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).
21. Sunrisepeak

    added a commit that references this issue on Oct 4, 2026

    mcpp-language-server 0.0.11: completion comes up in files that import…

    ...

    a0cd29b
22. Sunrisepeak commented on Oct 7, 2026

    

    Sunrisepeak

    on Oct 7, 2026

    OwnerAuthor

    More actions

    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.
23. Sunrisepeak commented on Oct 7, 2026

    

    Sunrisepeak

    on Oct 7, 2026

    OwnerAuthor

    More actions

    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 and Unexpected SIGPIPE during 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.md in draft PR #46.

    Source: vscode-languageclient/lib/common/client.js 10.1.1: start() owns a separate internal _onStart promise; handleConnectionClosed() disposes the connection and resets it before the original initialization continuation necessarily settles; doInitialize() calls void 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.ts and extension.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.ts is 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.
24. Sunrisepeak commented on Oct 7, 2026

    

    Sunrisepeak

    on Oct 7, 2026

    OwnerAuthor

    More actions

    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_DESTROYED rejections 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 receives MessageWriteError (-32099), while the process separately receives ERR_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, then WritableStreamWrapper.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.ts and the real-payload test/suite/zCrashLoop.test.ts cover 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.
25. Sunrisepeak commented on Oct 8, 2026

    

    Sunrisepeak

    on Oct 8, 2026

    Last edited by Sunrisepeak

    OwnerAuthor

    More actions

    UP-26 — asynchronous preamble trace metadata outlives its filename

    Symptom: BuildPreamble trace args.File contains 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 FileName at Preamble.cpp's BuildPreamble and CreatePreamblePatch spans. json::Value(StringRef) retains borrowed storage, while JSONSpan can remain alive through a retained request Context after 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.
26. Sunrisepeak commented on Oct 8, 2026

    

    Sunrisepeak

    on Oct 8, 2026

    OwnerAuthor

    More actions

    UP-27 · clangd23.1: a default OverlayCDB command mangler is called unconditionally during module scanning

    • Symptom: the public OverlayCDB(&Base) constructor defaults its CommandMangler to null. OverlayCDB::getProjectModules nevertheless installs a nonempty callback that unconditionally calls that null mangler. A real required-module scan through this default overlay segfaults at address0; ordinary getCompileCommand already guards the same optional mangler.
    • Affected: confirmed source in the unmodified pinned llvmorg-23.1.0 source 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.
27. Sunrisepeak commented on Oct 8, 2026

    

    Sunrisepeak

    on Oct 8, 2026

    OwnerAuthor

    More actions

    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.
28. Sunrisepeak commented on Oct 8, 2026

    

    Sunrisepeak

    on Oct 8, 2026

    OwnerAuthor

    More actions

    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.
29. Sunrisepeak commented on Oct 11, 2026

    

    Sunrisepeak

    on Oct 11, 2026

    OwnerAuthor

    More actions

    UP-30 · One prerequisite module that does not compile leaves its importers with no module at all

    • Symptom: clangd 23.1 builds a file's prerequisite modules as one set: when one fails to compile (clangd 23 module builder: one failed module (hello.test) blanks ALL completions — "Failed to compile src/test.cppm" while the project toolchain builds it fine #47: hello.test), the importer gets no module, not even std, and completion answers nothing while the status looks ready.
    • Affected scope: every importer of a module that fails, transitively; the whole set is retried at every request.
    • Upstream: unfiled.
    • mcppls: WA-CLANGD-014 (0.0.8 M-1/M-2): the importers are answered by mcppls's own engine until the module changes. mcppls-clangd 0.0.13 patch 0028 builds and uses the modules that compile, reports the failed one with the compile's first error, and retries the set once the failed source changes; it declares partial-prerequisite-modules, which retires the workaround.
    • Evidence: clangd 23 module builder: one failed module (hello.test) blanks ALL completions — "Failed to compile src/test.cppm" while the project toolchain builds it fine #47; conformance module-faults, failure-at-base; mcppls-clangd PrerequisiteModulesTests.OneFailedModuleLeavesTheOthers, ci/module_resilience_canary.py, tests/e2e/module_dag.py (failure shape).
    • Removal/drop: drop 0028 when upstream serves an importer with the prerequisite modules that did build.
30. Sunrisepeak commented on Oct 11, 2026

    

    Sunrisepeak

    on Oct 11, 2026

    OwnerAuthor

    More actions

    UP-31 · Completion in a module importer waits without bound for its first preamble and for newly imported modules

    • Symptom: with modules support, completion waits for a file's first preamble (whose prerequisite modules may take minutes to build on a large project) and builds a module the draft newly imports synchronously; stock 23.1 answers at once from its fallback, without the imported names.
    • Affected scope: the first minutes of a cold or warm start on a module project; typing an import.
    • Upstream: unfiled (related: UP-25).
    • mcppls: mcppls-clangd 0.0.13 patch 0027: the first preamble is waited for at most 600 ms (--completion-first-preamble-wait-ms, TUScheduler StaleWithin) and a new import at most 250 ms (--completion-module-wait-ms); past them the answer is the fallback's or the attached modules', marked incomplete, so the client asks again. Declared as bounded-module-wait.
    • Evidence: Maintained engine: the first completion in a just-opened module importer waits for its first preamble #50, 0.0.12 follow-ups: completion waits for missing modules, build.mcpp autosave drops the targets' flags, Windows warm starts rebuild modules, the mcpp version is lost #52 item 1 (a large Windows project: no answer under 1 s for 184-208 s); TUSchedulerTests.StaleWithinGivesUpOnASlowFirstPreamble, tests/e2e/module_cold_completion.py.
    • Removal/drop: drop when upstream bounds these waits.
31. Sunrisepeak commented on Oct 11, 2026

    

    Sunrisepeak

    on Oct 11, 2026

    OwnerAuthor

    More actions

    UP-32 · Why a module is rebuilt, and what a file's prerequisites cost, is not logged at the default level

    • Symptom: a warm start that rebuilds modules it should reuse, or a slow first preamble with nothing rebuilt, can only be explained from a verbose log, and only by inference.
    • Affected scope: every investigation of module build performance.
    • Upstream: unfiled (observability).
    • mcppls: mcppls-clangd 0.0.13 patch 0026 logs at info, before each build, why the BMI it had is not reused (none for this command and prerequisites, with how many were built with others, or the input that changed, from a reporting read of the stale BMI), one line per file with its prerequisites' cost (reused, built, failed, reuse checks, builds), and why a preamble is not compatible. Declared as module-rebuild-reasons; mcppls 0.0.13 counts the reasons in its startup line and report.
    • Evidence: 0.0.12 follow-ups: completion waits for missing modules, build.mcpp autosave drops the targets' flags, Windows warm starts rebuild modules, the mcpp version is lost #52 item 3; ci/module_resilience_canary.py.
    • Removal/drop: drop when upstream logs the same at its default level.