the measured graph moves onto the wave - #450
Merged
Merged
Conversation
…shed `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.
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.
What moves
tests/openkal/pins.toml→ openkal-llvm-runtime 0.13.0, registered and published in the preceding PR (#449). It pins openkal-musl 0.18.0 → openkal-linux 0.15.0, openkal-windows 0.10.0, openkal-macos 0.12.0 — the first graph in which all three implementations declare which interfaces of the layer they provide.Also:
mcpp→ 2026.9.20.1 in pins.toml and inopenkal-compat.yml(that workflow fails the run when the two disagree),MCPP_VERSION→ 2026.9.20.1 invalidate.yml, andlatest_mcpp→ 2026.9.20.1.Why the graph pin matters to a measurement
Below it, a member
srequires-interfaceswas answered on two implementations and **silently unanswered on the third** — openkal-macos carried no array, and mcpp treats a provider that states nothing as stating nothing, not as providing nothing. A measurement taken there recordsbuilds` for a member whose requirement nothing checked.min_mcppdoes not moveBoth new manifest keys are top-level tables, which an older engine ignores (it refuses an unknown member of a table it knows — that asymmetry is why both are shaped this way). Measured against the published 2026.9.18.3 archive: the absence table was first written as
[c-abi].absentand that binary refused openkal-musl`s whole manifest on every target; top-level, the same binary builds it. All 231 descriptors parse under 2026.9.18.3, so the descriptor grammar this floor governs is unchanged.The baseline this run will be compared against
From the preceding run on the old graph — 60 member×target results: 50 pass (47 of them
runs (posix)), 10 fail:windows.h, reached through the borrowed__CYGWIN____cxa_thread_atexitlinux/uapi headerarc4random_bufcurl_off_tThe first two groups are known and recorded (design §5.3 and
2026-09-20-cxa-thread-atexit-finding.md). This move is what makes the next run comparable against them.Verification
compat.py selftestmcppvs openkal-compat.ymlmcpp searchon the published index lists it