The std cache key of the clang MSVC row does not hold the MSVC version clang derives from cl.exe

[speak-agent]

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).

[speak-agent]

Fixed in mcpp 2026.9.30.2 (#747).

On the clang *-windows-msvc row, mcpp now reads the version of the toolset's cl.exe from its VS_FIXEDFILEINFO, as clang does: bin/Host{x64|x86}/<target>/cl.exe of the toolset directory, where clang 22 names no other host directory. The version is passed as -fms-compatibility-version together 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 the cl.exe build. A std module compiled on one runner image could therefore be served to another image whose cl.exe differs under the same 14.51.36231 directory, which is the mismatch reported here (msvc19.51.36260 against msvc19.51.36257). When no cl.exe exists where clang looks, no version is passed and clang falls back as before. A clang build for *-windows-msvc rebuilds 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.