Repository navigation
The std cache key of the clang MSVC row does not hold the MSVC version clang derives from cl.exe #746
Description
Activity
- added a commit that references this issue
on Sep 30, 2026 Fixed in mcpp 2026.9.30.2 (#747).
On the clang
*-windows-msvcrow, mcpp now reads the version of the toolset'scl.exefrom itsVS_FIXEDFILEINFO, as clang does:bin/Host{x64|x86}/<target>/cl.exeof the toolset directory, where clang 22 names no other host directory. The version is passed as-fms-compatibility-versiontogether with the toolset and SDK words, so it appears on the compile line, the std module precompile, the build.mcpp host compile and the link line, and it is part of every cache key. Before this, the key identified the toolset only by its directory, and a directory name does not determine thecl.exebuild. A std module compiled on one runner image could therefore be served to another image whosecl.exediffers under the same14.51.36231directory, which is the mismatch reported here (msvc19.51.36260againstmsvc19.51.36257). When nocl.exeexists where clang looks, no version is passed and clang falls back as before. A clang build for*-windows-msvcrebuilds once after the upgrade, because its commands gain the word.Criteria:
- e2e 760 on the Windows runners: both builds state one MSVC compiler version, and the pinned build, which ignores a
VCToolsInstallDir, states the same version as the default one. - Unit tests: the fixed-file-info reading, a signature that is not the structure, the target's compiler chosen under both host directories, and the link model word.
- The Windows e2e shards of 2026.9.30.2: a selected workspace member declares as the root, the clang MSVC row states its compiler version (#746), and a shared member is compiled once per configuration #747 and of the release pass.
The mechanism stated in this issue is the one the change closes. The cross-image cache restore that produced it has not been reproduced on demand.
- e2e 760 on the Windows runners: both builds state one MSVC compiler version, and the pinned build, which ignores a
Observation
e2e 760 (
760_msvc_toolset_is_chosen_once.sh) failed once on the Windows e2e leg of #745 (job 109769581840) and passed on a rerun of the same commit. The failing compile was leg 2 (the toolset pinned to the runner's default,14.51.36231, with aVCToolsInstallDirnaming a fake 14.99.0):mcpp-sandboxcacheBoth images report the default toolset
14.51.36231, and the two MSVC versions that clang derived differ (19.51.36260 and 19.51.36257).Hypothesis (not yet measured on a runner)
The build fingerprint and the std cache key of the clang MSVC row hold the toolset directory (
-Xmicrosoft-visualc-tools-root) and the SDK, but not the MSVC version clang derives fromcl.exe(-fms-compatibility-version, embedded in the BMI's target). Two images whosecl.exediffer under one toolset directory name then share a std entry, and a cache restored from one image serves the other.Criterion for a fix
On one machine, two
cl.exebuilds under one toolset directory name produce two std cache keys; equivalently, the MSVC version clang derives is part of the key (or is passed explicitly as-fms-compatibility-versionfrom the recorded toolset).