From bda5d8984a2a5a6dfb3cdec51f4a0e0a19f8e7da Mon Sep 17 00:00:00 2001 From: sunrisepeak Date: Mon, 21 Sep 2026 00:56:11 +0800 Subject: [PATCH] the measured graph moves onto the wave, now that its runtime is published `tests/openkal/pins.toml` moves to openkal-llvm-runtime 0.13.0, which was registered and published in the preceding change. That version pins openkal-musl 0.18.0, which pins openkal-linux 0.15.0, openkal-windows 0.10.0 and openkal-macos 0.12.0 --- the first graph in which ALL THREE implementations declare which interfaces of the layer they provide. WHY THAT MATTERS TO A MEASUREMENT AND NOT ONLY TO A BUILD. Below this pin a member's `[kernel-abi] requires-interfaces` was answered on two of the three implementations and silently unanswered on the third: openkal-macos carried no array, and mcpp treats a provider that states nothing as stating nothing rather than as providing nothing. A measurement taken there records "builds" for a member whose requirement nothing checked. `mcpp` moves to 2026.9.20.1 because the set difference being measured is what that release added, and openkal-compat.yml's pin moves with it --- that workflow fails the run when the two disagree. validate.yml moves too: an index that lints itself with an engine ten releases behind validates against something no user runs. `latest_mcpp` moves. `min_mcpp` DOES NOT, and the reason is recorded beside it: both new manifest keys are top-level tables an older engine ignores, and all 231 descriptors parse with 2026.9.18.3, so the descriptor grammar this floor governs did not change. Raising it would take the whole index from every client below it for a diagnostic note they merely would not receive. THE BASELINE THIS REPLACES, from the preceding run on the old graph: 60 member-target results, 50 pass (47 of them `runs (posix)`), 10 fail --- four on `windows.h` reached through the borrowed `__CYGWIN__`, two on `__cxa_thread_atexit`, two on `linux/` uapi headers, one `arc4random_buf`, one `curl_off_t`. The first two groups are known and recorded; this move is what lets the next run be compared against them. --- .github/workflows/openkal-compat.yml | 2 +- .github/workflows/validate.yml | 2 +- index.toml | 21 ++++++++++++++++++++- tests/openkal/pins.toml | 24 +++++++++++++++++++++--- 4 files changed, 43 insertions(+), 6 deletions(-) diff --git a/.github/workflows/openkal-compat.yml b/.github/workflows/openkal-compat.yml index b5625702..4e9bf3fd 100644 --- a/.github/workflows/openkal-compat.yml +++ b/.github/workflows/openkal-compat.yml @@ -33,7 +33,7 @@ env: # run if this drifts from pins.toml. See the comment beside `mcpp` in # pins.toml for why this pin, not just validate.yml's, is gated by the # index floor. - MCPP_VERSION: "2026.9.18.3" + MCPP_VERSION: "2026.9.20.1" XLINGS_NON_INTERACTIVE: "1" jobs: diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml index 59f866b1..18d973a2 100644 --- a/.github/workflows/validate.yml +++ b/.github/workflows/validate.yml @@ -301,7 +301,7 @@ env: # is a cold one (mcpp's build-cache epoch moved from 2 to 3 in this same # release, because the old cache key did not cover the realised [c-abi] # environment). - MCPP_VERSION: "2026.9.18.3" + MCPP_VERSION: "2026.9.20.1" jobs: lint: diff --git a/index.toml b/index.toml index 6182e10a..33d531bf 100644 --- a/index.toml +++ b/index.toml @@ -79,7 +79,26 @@ # raising the floor was gated on the engine, not on those two packages, and # gating on both at once would have held this raise hostage to something it # does not need. +# ── 2026-09-20: latest_mcpp -> 2026.9.20.1, min_mcpp DELIBERATELY UNCHANGED ── +# +# That release adds two manifest keys, `[kernel-abi]` and `[c-abi-absent]`, and +# neither asks anything of this floor. mcpp IGNORES a top-level table it does +# not know and REFUSES an unknown MEMBER of a table it does know; both keys are +# top-level, so a client stopped at 2026.9.18.3 loads the manifests carrying +# them and loses only the check. +# +# Measured, not assumed. The absence table was first written as +# `[c-abi].absent`, and the published 2026.9.18.3 archive refused openkal-musl's +# whole manifest on every target with `[c-abi] has no member 'absent'`; moved to +# the top level, that same published binary builds it, and openkal-musl's own CI +# pins 2026.9.18.3 and is green on 0.17.0 and 0.18.0. All 231 descriptors parse +# with 2026.9.18.3 as well, so the DESCRIPTOR grammar --- what this floor +# actually governs --- did not change either. +# +# Raising it would cost every client below the floor the WHOLE index (E0006 at +# the index-open choke point) for a diagnostic note they merely would not have +# received. [index] spec = "1" min_mcpp = "2026.9.18.3" -latest_mcpp = "2026.9.18.3" +latest_mcpp = "2026.9.20.1" diff --git a/tests/openkal/pins.toml b/tests/openkal/pins.toml index 529f4d3c..3d54d6b6 100644 --- a/tests/openkal/pins.toml +++ b/tests/openkal/pins.toml @@ -4,7 +4,7 @@ # `runtime` is the C++ runtime for openkal; it pins openkal-musl exactly, and # openkal-musl selects the openkal implementation for each target, so this one # version names the whole graph. -runtime = "0.12.0" +runtime = "0.13.0" toolchain = "llvm@22.1.8" # `mcpp` here moves together with index.toml's `min_mcpp` and # .github/workflows/openkal-compat.yml's own MCPP_VERSION (that workflow @@ -18,7 +18,25 @@ toolchain = "llvm@22.1.8" # index requires mcpp >= 2026.9.18.1 but this is mcpp 2026.9.17.3 [E0006]" # before a single line of the member's own source is read. # -# `runtime` MOVES HERE NOW, AND UNTIL IT DID THE WINDOWS LEG MEASURED A GRAPH +# 2026-09-20: `runtime` -> 0.13.0, THE FIRST GRAPH IN WHICH EVERY IMPLEMENTATION +# DECLARES ITS INTERFACES. It pins openkal-musl 0.18.0, which pins +# openkal-linux 0.15.0, openkal-windows 0.10.0 and openkal-macos 0.12.0 --- the +# last of those is the release that closed the gap. Below it a member's +# `[kernel-abi] requires-interfaces` was answered on two of the three +# implementations and silently unanswered on the third, and a measurement taken +# there records "builds" for a member nothing had checked. +# +# 0.13.0 WAS REGISTERED AND PUBLISHED BEFORE THIS LINE MOVED, in a separate +# change. Moving both at once fails EVERY member at once: `compat.py` gives each +# copied member an `[indices] compat = { path = }` so a changed +# DESCRIPTOR is measured, and that serves resolution but not INSTALLATION, which +# is delegated to xlings and reaches only the repositories it has synced. Since +# the runtime pin is in every member's manifest, a version that exists only in +# this checkout fails all of them, and the failure reads as a compatibility +# result rather than as a missing registration. +# +# (the note below is from the previous move, and its reasoning still holds) +# `runtime` MOVED, AND UNTIL IT DID THE WINDOWS LEG MEASURED A GRAPH # WITH NO `[c-abi]` IN IT. openkal-llvm-runtime 0.12.0 (openkal-musl 0.16.0, # openkal 0.14.0) is the first pinned graph in which a package declares the # block, so it is the first in which mcpp realises `presents = "posix"` at all: @@ -33,7 +51,7 @@ toolchain = "llvm@22.1.8" # openkal-musl 0.16.0 and openkal-llvm-runtime 0.12.0), because a pin that # moves onto an unreachable or divergent asset fails every member at once and # reports it as a compatibility result. -mcpp = "2026.9.18.3" +mcpp = "2026.9.20.1" targets = ["x86_64-linux-gnu", "x86_64-windows-gnu"]