Repository navigation
Bump actions/checkout from 4 to 7 - #4
Closed
dependabot[bot] wants to merge 2 commits into
Closed
dependabot[bot] wants to merge 2 commits into
dependabot[bot] wants to merge 2 commits into
Conversation
A C++ modules language server: one set of module semantics on every compiler, for editors, coding agents and CI. See README.md and CHANGELOG.md.
Bumps [actions/checkout](https://github.com/actions/checkout) from 4 to 7. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v4...v7) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
Bot
deleted the
dependabot/github_actions/actions/checkout-7
branch
September 21, 2026 20:16
Owner
|
Included in the release commit 255d962 (this repository keeps a single release commit) together with the other dependency updates, and verified by CI there. Dependabot now groups updates into one PR per ecosystem. |
Sunrisepeak
added a commit
that referenced
this pull request
Oct 10, 2026
Sunrisepeak
added a commit
that referenced
this pull request
Oct 10, 2026
Sunrisepeak
added a commit
that referenced
this pull request
Oct 10, 2026
Sunrisepeak
added a commit
that referenced
this pull request
Oct 10, 2026
Sunrisepeak
added a commit
that referenced
this pull request
Oct 10, 2026
Sunrisepeak
added a commit
that referenced
this pull request
Oct 10, 2026
Sunrisepeak
added a commit
that referenced
this pull request
Oct 11, 2026
Sunrisepeak
added a commit
that referenced
this pull request
Oct 11, 2026
… built again to the same bytes keeps its importers, and owned lookups try their last slot first
Sunrisepeak
added a commit
that referenced
this pull request
Oct 11, 2026
…er's key names its producers' bytes, and a file's last prerequisites are kept
Sunrisepeak
added a commit
that referenced
this pull request
Oct 11, 2026
…l preamble holds while its own reads replay unchanged
Sunrisepeak
added a commit
that referenced
this pull request
Oct 11, 2026
Sunrisepeak
added a commit
that referenced
this pull request
Oct 11, 2026
…vy headers with modules, build.mcpp, mcpp formatting, crash recovery, linux-arm64 again (#46) * feat: the 0.0.12 joint work -- engine identity, mcpp formatting, crash recovery, save planning The product side of the 0.0.12 joint work with mcppls-clangd, without the raw evidence it produced (that is in the evidence-0.0.12 archive): - a payload binds its engine's immutable identity (payload version 4, engine.json: version, LLVM base and commit, fork commit, patch-series digest, platform, binary SHA-256, features), verified at assembly and at startup; a maintained engine selects the kit of its LLVM base, and workarounds retire only for a capability the verified identity declares - format.fallbackStyle: without a project .clang-format, an mcpp project gets the pinned mcpp style when the bundled engine declares it - VS Code: a server exiting during initialize, or a failed protocol write, settles the client before a fresh one starts (WA-VSCODE-003/004); recovery shares the manual lifecycle queue and the crash budget; the log path is learned from stderr before a report can be interrupted - a body save whose disk and draft module structure the plan already covers does not schedule another whole-project plan - the model gateway's initialize has its own bounded deadline - Darwin pipes to children are protected from SIGPIPE per descriptor - CI keeps bounded timing and stability diagnostics for native runs * fix: 0.0.12 part 3 -- linux-arm64 is bundled again, engine parts are taken as built, save planning holds on aliased paths - linux-arm64 returns to the lock, the release manifest, the extension and every CI matrix: its removal was a scope decision with no technical failure behind it, and the maintained engine is built for it at the Ubuntu 20.04 floor (glibc 2.31 instead of LLVM's own build's 2.34). - mcppls.pack.clangd takes a maintained engine part (mcppls-clangd's clangd-<version>-<platform>.tar.gz, whose clangd/ holds engine.json) byte for byte: no strip, no thinning, no re-signing, so the identity the payload verifies names the bytes it ships. - test_save_plan failed on macOS and Windows only: its hand-built model named files under the raw temporary directory while the workspace resolves a document's URI canonically, as a loaded model does (/var is /private/var, Windows may hand out a short name). Reproduced on Linux with a symlinked TMPDIR (the same four assertions), fixed by giving the fixture the canonical root a loaded model has. - the default background-index priority applies on macOS only, the one host with evidence for it (Linux maps both priorities to SCHED_IDLE; Windows' background mode also lowers I/O priority, unmeasured for indexing). - format.fallbackStyle compares `auto` case-insensitively, like `mcpp`. - payload version 4 is a named constant shared by assembly and verification. - Intel macOS build scaffolding goes (its cross target, the __bzero stub, the Neovim bootstrap, the x86_64 SIGPIPE path); 0.0.11 never shipped it. - mcppls-devtools check tree: no tracked file above 1 MiB, none generated. - the xlings descriptors depend on the LLVM base of a maintained engine. - CHANGELOG 0.0.12, install floors (glibc 2.31, macOS 12), the part 3 plan and its record; the earlier status documents point at the evidence archive. * test(vscode): the initialize crash is staged with a waiting stand-in, not won in a polling race The server answers initialize within milliseconds, so finding it between its spawn and the client's start by polling the process table was a race; under PRoot on linux-x64 the poll lost it for a full minute. MCPPLS_SERVER, read at every start, now names a stand-in that waits three seconds before becoming the real server, so the test kills a process whose initialize is certainly unanswered, and the recovery it checks is unchanged. The format fallback line of the initialization options moves below the engine.workers comment it had split. * fix(engine): mcppls-clangd's module reports are read, and its proved fixes retire their workarounds Running the conformance fixtures against the maintained engine, which product CI had never done, showed where it speaks differently from stock clangd: - A failed prerequisite is reported per importing file, "Failed to build module prerequisites for <file>; due to module worker failed: <source>:...", naming the unit that failed rather than the module. The parser took "prerequisites for <file>" for a module name, so no module-failed diagnostic, closure containment or std kit fallback happened (module-faults). It now reads the importer and the failed unit, and the module is the one the plan gave that unit. - An import with no unit in the project is kept textual: "Keeping import of third-party module <name> textual; no module unit for it in this project". It is an unresolved module, as stock clangd's "Don't get the module unit" is, so it gets its stand-in (partial-scan-standins). - WA-CLANGD-001 and WA-CLANGD-010 retire for an engine whose verified identity declares module-directive-recovery and const-correctness-views, as WA-006 already did for module-directive-diagnostic-ranges. Conformance checks take "retired-by": a check watching a defect the payload's engine is proved free of holds and says why (workaround-canaries' 001 and 010, typing-import-spin's T2); against any other clangd it runs. Both log formats keep working for an external stock clangd. * feat(payload): every platform bundles mcppls-clangd 0.0.12 packaging/payload.lock.json names mcppls-clangd v0.0.12's clangd-23.1.0-mcppls.0-<platform>.tar.gz for linux-x64, linux-arm64, darwin-arm64 and win32-x64 (each sha256 from two downloads and the digest the release publishes beside the asset); the stock clangd archives no platform names go, the kit sources stay. clangd-version and CLANGD_VERSION are 23.1.0-mcppls.0; the kit keeps the LLVM base, 23.1.0. The engine's identity declares module-directive-recovery, so the checks that watch WA-CLANGD-001 itself being on (typing-import T6) or its disk-side set-aside (typing-autosave T3) are retired-by it, as the canaries are. * fix(engine): the maintained engine compiles in process under PRoot, and the scenario tests read its owned cache The first product CI run with mcppls-clangd bundled showed three more places where the product assumed stock clangd: - Under PRoot every process is traced call by call, and mcppls-clangd's supervised compiler worker is a process per module; with PROOT_NO_SECCOMP clangd was still preparing after 20 s. For a verified maintained engine under a detected sandbox the server passes --modules-builder-worker-policy=in-process (with the owned cache's payload bounds off, which need a worker), the upstream way. - mcppls-clangd's owned cache publishes every module file as .owned-payload-v1/generation-<slot>-<n>/payload.pcm. The scenario tests took a module file's unit from its directory and its module from its file name, so a warm start that reused all 111 xlings BMIs counted 135 rebuilds, SC4 found no std file and U11 nothing to truncate. An owned payload's unit is now the source its control block names, its module the one that source declares, and a new generation holding the bytes of a payload there was is a read copy, not a build. - In a module importer that was just opened, mcppls-clangd waits for the file's first preamble before it answers a completion (issue #50), where stock clangd answers at once without imported declarations. Typing checks with "firstOpenSeconds" now measure that wait on its own, with its own budget, and hold the typing after it to the unchanged budgets: ux-xlings U5 locally, first answer 6.1 s after opening, then p95 0.14 s (stock: 0.21 s). * test(conformance): the Windows crash on `import hello.` is retired by directive recovery too typing-import-spin's T2-crash-restarted is the Windows face of the defect T2 watches on Linux and macOS (clangd 23.1 crashes there instead of spinning); an engine that declares module-directive-recovery has neither. * fix(engine): a planned module kept textual is taken as unresolved only when the engine says so again mcppls-clangd reports "Keeping import of third-party module <name> textual; no module unit for it in this project" both for a unit whose scan keeps failing (partial-scan-standins, reported at every attempt) and once while its provider index catches up with a database whose provider moved. Under PRoot the second came 7 s after the move, past DATABASE_REREAD, and typing-import's hello.greet got a stand-in that pushed greet.cppm out of the database and restarted clangd. For a module the plan gives a unit, a report is now taken only when repeated at least 2 s after the first (and the count starts again when its provider changes); a module the plan has no unit for is taken at once, as before. * fix(engine): a module mcppls-clangd's owned cache already has a BMI of is not primed again module_already_built_ found a BMI only in stock clangd's layout, <source>-<hash>/<command>/<module>.pcm, so with mcppls-clangd bundled every warm start primed all of a project's modules again: on four cores, xlings' first ready took 14.1 s against stock clangd's 7.2 s, and every importer's prerequisites queued behind the 111 prime units (completion p95 at the 1 s budget, recovery after a kill over 25 s on CI). An owned payload's unit is the first source path its control block names; the units the owned cache keeps are read once per plan, as the stock listing is, and the command check from module-builds.json is unchanged. On four cores the warm start is now ready in 3.0 s and typing completion p95 is 0.23 s (stock clangd: 7.2 s, 0.19 s). * fix(engine): the bundled maintained engine is the tested one, so its 23.1 workarounds follow its features * fix(engine): an engine that recovers from an unresolved import gets no stand-ins for importers and sets no file aside for one (WA-CLANGD-013) * ci: a pull request's payloads can carry a mcppls-clangd PR's build, tested before the engine is released * docs(plan): part 3 records what the comparison against stock clangd found and how each gap closed * test(conformance): modules mixed with Qt headers and with <windows.h>, for answers, latency while typing, crashes and stalls * ci: test with mcppls-clangd PR #4's build (run 38058142325) * fix(engine): a doomed file closed in clangd is no spin when it goes back, and a probe's syntax error outside the workspace is no project issue * ci: test with mcppls-clangd PR #4's build (run 38063670345) * fix(engine): a planned module kept textual is taken on its second report half a second on; the Qt fixture finds the distribution's Qt * ci: test with mcppls-clangd PR #4's build (run 38068427206) * docs(changelog): 0.0.12 keeps preambles for files mixing headers with imports, and completion stops waiting on rebuilds * test(conformance): a failed fixture prints the server log lines it names; the module fixtures name clangd's preamble decisions * ci: test with mcppls-clangd PR #4's build (run 38072806771) * fix(engine): preparation given work again after idling starts its stall clock then (#49); a planned unit clangd could not scan is unresolved on its first kept-textual report * ci: test with mcppls-clangd PR #4's build (run 38078354274) * test(vscode): an entry removed while the workspace is hashed is not part of what the run left behind * test(server): the implementation-unit timing test leaves a loaded runner a second between steps * ci: test with mcppls-clangd PR #4's build (run 38085562071) * test(conformance): the module fixtures run at the default log level again, as an editor does * fix(engine): mcppls-clangd's owned module cache gets three quarters of the workspace's cache budget, not its own 1 GiB * ci: test with mcppls-clangd PR #4's build (run 38096424985) * fix(engine): a cache budget past 3 PiB still gives mcppls-clangd a bound its option can hold * fix(engine): the owned cache bound is given to mcppls-clangd on Linux only, the one platform its workers are isolated on * ci: test with mcppls-clangd PR #4's build (run 38102113449): a module built again to the same bytes keeps its importers, and owned lookups try their last slot first * ci: test with mcppls-clangd PR #4's build (run 38107318525): a consumer's key names its producers' bytes, and a file's last prerequisites are kept * ci: test with mcppls-clangd PR #4's build (run 38115543969): a textual preamble holds while its own reads replay unchanged * test(conformance): an edit keeps the file's line endings, as an editor does: rewriting a CRLF file's at the first keystroke rebuilt its preamble * ci: test with mcppls-clangd PR #4's build (run 38126436000), the one to be released * feat: build.mcpp, its libraries and mcpp's engine interface have the features of target code (#51) mcpp 2026.10.11.1 (mcpp-community/mcpp#797) describes its build programs in the build database: build.mcpp, the libraries of [build-dependencies] and the engine interface, in sets of the `build-program` configuration whose visible sets stay within it. - build.mcpp is C++ because mcpp's command says `-x c++`; the translations dropped it with the build's other spellings of the language, and clangd refused the file. The plan states the language again for a unit whose name tells the Clang driver none. - The default context reads the targets first: a package in both tables is read as the targets build it, a build program's own version of a module the targets provide is read in its own context without an ambiguity, and build programs with a toolchain of their own (a cross build) are read in the context <package>:build, which says so in the file. - The module index knows each unit's configuration: an import across the two is an error at the import (build-program-module, target-module), import completion offers one configuration's modules, and module navigation prefers them. - mcpp's engine interface is read-only: formatting, code actions and renames never edit it, and VS Code opens <MCPP_HOME>/engine/*/modules read-only. - A .mcpp file no set describes (an older mcpp) is not given to clangd, and says which mcpp describes it. - Every editor integration treats .mcpp as C++; Zed's README gives the file_types setting. Tests: unit tests for the plan and the module index; the conformance fixture mcpp-build-programs against a real mcpp 2026.10.11.1 (installed in CI beside the pinned mcpp, MCPP_BUILD_PROGRAMS_VERSION) on Linux, macOS and Windows, mcpp-build-programs-cross from its recorded output with a second toolchain, an undescribed build.mcpp in mcpp-emit, and the runner's new `request` check. S1 §7 describes the configuration; validate.py checks mcpp's build-program sets. * test(conformance): ux-modules-windows' typing p95 is 1.1 s, what the Windows runner measures with a margin; the engine share keeps holding clangd to answering * ci: the mcpp that describes build programs comes from mcpp's own release, checksum checked: the index snapshot the pinned xlings syncs did not have 2026.10.11.1 * test(conformance): ux-modules-windows' engine share is 0.65, what the Windows runner measures (0.72-0.90) with a margin * build: the payload pins the released mcppls-clangd v0.0.12 (23.1.0-mcppls.0) on every platform; the candidate engine file goes * ci: a payload with no candidate engine assembles on macOS too (an empty array under set -u is unbound to its bash 3.2) * docs(changelog): 0.0.12 is dated the day it is released
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps actions/checkout from 4 to 7.
Release notes
Sourced from actions/checkout's releases.
... (truncated)
Changelog
Sourced from actions/checkout's changelog.
... (truncated)
Commits
3d3c42eprep v7.0.1 release (#2531)2880268escape values passed to --unset (#2530)12cd223trim only ascii whitespace for branch (#2521)62661c4skip running unsafe pr check if input is default (#2518)e8d4307Bump the minor-actions-dependencies group with 2 updates (#2499)631c942eslint 9 (#2474)4f1f4aeBump actions/upload-artifact from 4 to 7 (#2476)ba09753Bump actions/checkout from 6 to 7 (#2488)b9e0990Bump docker/login-action from 3.3.0 to 4.2.0 (#2479)e8cb398Bump docker/build-push-action from 6.5.0 to 7.2.0 (#2478)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)