Repository navigation
The std cache key of the clang MSVC row does not hold the MSVC version clang derives from cl.exe #746
Description
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 a VCToolsInstallDir naming a fake 14.99.0):
error: AST file '...\pcm.cache\std.pcm' was compiled for the target 'x86_64-pc-windows-msvc19.51.36260'
but the current translation unit is being compiled for target 'x86_64-pc-windows-msvc19.51.36257'
error: module file ...\std.pcm cannot be loaded due to a configuration mismatch with the current compilation
| Job | Runner image | mcpp-sandbox cache |
760 |
|---|---|---|---|
| 109757602629 (#745, 9b8cdd7) | windows-2025-vs2026 20260925.250.1 | not found, saved at the end | pass |
| 109769581840 (#745, ac4beb8) | windows-2025-vs2026 20260922.246.2 | restored (the one saved above) | fail |
| 109778980139 (rerun of the above) | windows-2025-vs2026 | not found | pass |
Both 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 from cl.exe (-fms-compatibility-version, embedded in the BMI's target). Two images whose cl.exe differ 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.exe builds 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-version from the recorded toolset).
Activity
2026.9.30.2: a selected workspace member declares as the root, the cl…
speak-agent commentedon 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:
VCToolsInstallDir, states the same version as the default one.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.