Repository navigation
[temp][do not merge] probe: i686-windows-msvc import std under LLVM 23.1.3 (#781 part 3, G1/G2) - #788
Closed
Sunrisepeak wants to merge 27 commits into
Closed
Sunrisepeak wants to merge 27 commits into
Sunrisepeak wants to merge 27 commits into
Conversation
23.1.3 is the first point release carrying the macOS 27 arm64e.x1 ld64.lld fix (llvm-project#222721, backported to release/23.x as ee66426) — the release #669 was blocked on. clang 23.1.0's MSVC STL std-module defect was fixed in 23.1.1 (#640, llvm-project#218152). The line move (single PR per SPEC-009 §10.6): - kKnownTargets: the 17 llvm rows move 22.1.8 -> 23.1.3; the gcc rows stay. - Host defaults: macOS and Windows-with-MSVC move to llvm@23.1.3, resolving the [toolchain] macos/windows deviations (SPEC-009 §12). Linux keeps gcc@16.1.0 by design — native glibc ABI — now recorded as a §4.1 reason at the single pin site, with the gcc@15.1.0-musl reason beside it. - All four known-red legs (#669) become unconditional normal legs; the known-red floor assertion moves to zero. The xcode-27 legs went green on rerun and #669 is closed. - Readers move with the tables: workflows, the macOS action, CI tools, e2e fixtures, tests/matrix/expected.tsv, examples, user docs (en/zh); SPEC-009 v0.4 records the move. - libc++ 23 adaptation the gate caught: _LIBCPP_BEGIN_NAMESPACE_STD opens under the ODR-signature abi_tag pragma, and clang refuses to add abi_tag on a redeclaration — e2e 133's verbose_abort override now spells the namespaces by hand. The #782 repair: a held unserved-target diagnosis no longer skips the toolchain install. A declared or --target toolchain resolves and installs even when no payload here serves the target — a retargetable clang plus a graph package supplying the target's system is the arrangement the openkal rows exist for, and the skip fired before the graph release could run the moment the suite stopped installing the pinned version out of band (measured on the openkal macos leg, twice). When the install itself fails and the diagnosis stands, it releases there. e2e 890 pins the contract on the mac/windows legs. The e2e toolchain-version abstraction: tests/e2e/_toolchain_env.sh is the one place a test learns a toolchain version — override, newest installed, fallback constant, per family — and the llvm family's ~90 literals across 38 scripts now read it. The next line move edits one file here. _llvm_env.sh becomes an alias shim. Closes #780. Closed #669 (xcode-27 legs green on rerun). Files #782 as the remaining openkal macos regression this repair addresses.
Add the ARM64 first-run pin, native GNU host row and runtime paths; preserve explicit musl and existing user defaults. Add cold payload admission, complete xcode-27 shards, respect MCPP_HOME and capture Windows compiler failure evidence. Prepare release 2026.10.8.1. Native ARM64 remains preview until the coordinated resources and client release pass the measured integration gates. Refs: #784, #783
Exercise standard modules, exceptions, threads, 16-byte atomics, a C shared-library consumer and relocated self-contained deployment. Record managed loader/header resolution, require native openkal execution and preserve fresh-install Windows failure diagnostics. Document the explicit compiler-and-target migration command and its publication prerequisites. Refs: #784
…the MSVC STL coroutine guards
Sunrisepeak
added a commit
that referenced
this pull request
Oct 8, 2026
… out LLVM 23.1.3 Part 3, from the review of #781 and #786. - clang 23 does not predefine __cpp_impl_coroutine for i686-pc-windows-msvc, so the MSVC STL's <coroutine> is empty: the C++23 std module stops inside <generator>, and code that uses coroutines stops at "use of undeclared identifier 'std'". mcpp follows the compiler and appends a note to either failure (mcpp.toolchain.msvc_coroutines): C++20 first, where import std and import std.compat build, and llvm@22.1.8 for that target as an option. The note is decided after the failure from the failed command and a -dM -E probe of the same compiler, on the std precompile, the ninja path and the fast path alike. Measured on probe PR #788. - The graph C library note fires only when the C library is the graph's: the plan checks cAbi.fromGraph(), and the fast path reads .mcpp-graph-c-library beside build.ninja. A native build on a managed glibc carries -nostdlibinc too, which made the token alone a wrong answer. - GCC without a usable subos takes -isysroot <C library payload>, replacing the sysroot recorded when the compiler was built. - No host system header directory is searched on a managed C library; a project that needs one writes -idirafter /usr/include (e2e 891). - aarch64-linux-gnu is preview until the released engine is consumed on a clean ARM64 host; README rows and the baremetal sample name LLVM 23. - docs/20 (en/zh), SPEC-006 §3.8, SPEC-009 §6.4, CHANGELOG. Refs: #786
Sunrisepeak
added a commit
that referenced
this pull request
Oct 8, 2026
…routine note and no host system headers (#781) Moves the LLVM line to 23.1.3, makes native Linux aarch64 select LLVM 23.1.3 with the GNU target, and closes the review findings of Part 3. LLVM line and defaults - kKnownTargets' llvm rows, the macOS and Windows-with-MSVC first-run defaults and the self-hosting manifest move to llvm@23.1.3 (the first release with the macOS 27 arm64e.x1 linker fix). Linux x86_64 keeps gcc@16.1.0. Existing user declarations and the musl rows are unchanged. - Native Linux aarch64 defaults to llvm@23.1.3 on the managed glibc; aarch64-linux-gnu is preview until the released engine is consumed on a clean ARM64 host. xlings is pinned to 2026.10.8.1. - A declared toolchain for a graph-supplied target is installed even when no payload here serves the target; an engine-chosen one still releases the held diagnosis (#782). - AArch64 std modules and programs share compiler-rt settings; a self-contained ELF that embeds libunwind.a links with --unwindlib=none. Part 3 - clang 23 does not predefine __cpp_impl_coroutine for i686-pc-windows-msvc. mcpp follows the compiler and appends a note to the two failures that follow (the C++23 std module inside <generator>, and code that uses coroutines): C++20 first, llvm@22.1.8 for that target as an option. The std module case is decided from its command; the ninja and fast paths from the output. Measured on probe PR #788; e2e 892. - No host system header directory is searched on a managed C library: clang carries -nostdlibinc, GCC without a usable subos takes -isysroot <C library payload>. A project that needs a host header writes -idirafter (e2e 891). - The graph C library note fires only when the C library is the graph's, on the plan path and the fast path (.mcpp-graph-c-library). Tests and documents - tests/e2e/_toolchain_env.sh is the one place an e2e learns a toolchain version; the four-host target matrix (244 rows) is declared; ARM64 native admission, openkal cross and hosted-thread checks run in CI. - docs/20 and docs/21 (en/zh), READMEs, SPEC-006 v0.7 (§3.8), SPEC-009 v0.6 (§6.4), CHANGELOG. Closes #780 Closes #783 Refs: #784, #786
Member
Author
|
Probe finished. Its measurements (runs 37791590252 and 37792334189) set the 32-bit MSVC coroutine note shipped in 2026.10.8.1 (#781): C++20 |
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
2 participants
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.
Temporary probe for the LLVM 23.1.3 Part 3 plan (#781, #786). Based on the #781 head
c6dca54e; every other workflow is removed so only the probe runs. Nothing asserts; logs are in the job summaries and artifacts.import stdon i686-windows-msvc, C++23, llvm@23.1.3 — the reported failure and where it occurs; the same with llvm@22.1.8 via[target.i686-windows-msvc]and[target.x86-windows-msvc].std,std.compat, and the coroutine library itself).<coroutine>/<generator>and the std.ixx conditionals.Do not merge. Closed after the release ships.