From 2b871673afdafcc809e51be5e6303fbe9687f389 Mon Sep 17 00:00:00 2001 From: speak-agent Date: Sun, 20 Sep 2026 17:59:51 +0800 Subject: [PATCH] openkal measurement: the pinned graph declares [c-abi] for the first time tests/openkal/pins.toml moved `runtime` from 0.10.0 to 0.12.0. Below that version no package the pin resolves declares a `[c-abi]` block, so mcpp realises nothing for the target side and the Windows leg compiles as x86_64-w64-windows-gnu with `_WIN32` defined --- the condition every `#ifdef _WIN32` branch in the measured members selects on. Every Windows result recorded under 0.10.0 therefore measures the behaviour the declaration exists to replace rather than the declaration. The descriptors for both packages were already registered (#441, #442) and their two mirrors compared byte for byte before this move: openkal-musl 0.16.0 and openkal-llvm-runtime 0.12.0 each answer the same sha256 from the GitHub archive and the GitCode asset. Co-authored-by: Claude Code --- tests/openkal/pins.toml | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/tests/openkal/pins.toml b/tests/openkal/pins.toml index 61ead6df..529f4d3c 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.10.0" +runtime = "0.12.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,15 +18,21 @@ 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` does NOT move here: openkal-llvm-runtime 0.11.0 (the version that -# actually declares/consumes `[c-abi]`) is not published yet -- see the note -# in pkgs/o/openkal-llvm-runtime.lua. Bumping `mcpp` alone, ahead of it, -# changes nothing observable today: no package this pin resolves declares -# `[c-abi]`. Verified locally (not merely asserted): a full run of every -# member listed below against x86_64-linux-gnu, under 2026.9.18.1, reproduces -# the checked-in baseline exactly -- same 27 runs / 3 fails, same three -# members (expat, curl, cmp-module), same diagnostics character-for-character -# past the local path prefix. +# `runtime` MOVES HERE NOW, 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: +# below it the Windows target compiles as `x86_64-w64-windows-gnu` with `_WIN32` +# defined, which is the condition every `#ifdef _WIN32` branch in the measured +# members selects on. A result taken under 0.10.0 therefore says nothing about +# the declaration -- it measures the behaviour the declaration exists to +# replace. mcpp-community/mcpp#674 was opened against results of that shape. +# +# The two mirrors of both packages were compared byte for byte before this +# move (GLOBAL archive against the GitCode asset, sha256 equal for +# 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" targets = ["x86_64-linux-gnu", "x86_64-windows-gnu"]