[MoonCloud02]

tests/test_precompile_compute_guard.py fails on a Windows setup that has only llvm-mingw (the toolchain Hookshot Builder ships and HOOKSHOT_MINGW selects, as CONTRIBUTING.md's Windows setup describes): fatal error: 'windows.h' file not found. python -I -B tests/run_all.py therefore reports a failure on a clean contributor setup although nothing in the game is wrong.

Cause

The fixture was always compiled with --target=x86_64-pc-windows-msvc. llvm-mingw's clang++ does not look for Visual Studio or the Windows SDK, so for the MSVC target it has no <windows.h> (clang++ -v searches only its own resource dir and the legacy Microsoft Visual Studio 8-10 paths). The game itself never builds that way with llvm-mingw: third_party/a64-kit/tools/toolchain.py native_target() gives it --target=x86_64-w64-mingw32 -fms-extensions, which is what makes guarded_compute's __try/__except compile there.

Change

• tests/test_precompile_compute_guard.py: windows_target(cxx) asks the compiler -dumpmachine. A MinGW clang++ (*-windows-gnu / *mingw*) builds the fixture for x86_64-w64-mingw32 with -fms-extensions, as the game's build does. Any other compiler keeps the MSVC target, so CI's windows-2022 runner is unchanged.

Tested

Windows 11, llvm-mingw 20261104 (clang 23.1.5, -dumpmachine = x86_64-w64-windows-gnu), no clang on PATH other than llvm-mingw's:

Run	Before	After
tests/run_all.py precompile_compute_guard	FAIL (windows.h not found)	pass, cases 0-4
Mutant: guarded_compute without __try (copy of the source via --source)	n/a	caught: case 1: exit 0xc0000005, expected 0x0

So with the MinGW target the check still fails without the guard: SEH through -fms-extensions catches the injected access violation only when __try is there.

Full python -I -B tests/run_all.py on this branch: 355 passed, 29 skipped, 3 failed, none of them this test:

• test_recorder_sync: the llvm-mingw negative-control problem fixed by test: the recorder exit check catches the old destructor on llvm-mingw too #2240 (that PR's patch makes it pass here, 3 runs out of 3).
• test_vcore_fs_open, test_vcore_video_acquire: env_on on current main, tracked in main: test_vcore_fs_open and test_vcore_video_acquire no longer compile since #2042 met #2301 and #2322 #2379 / test: test_vcore_fs_open and test_vcore_video_acquire build again with env_on #2380.

Not tested

• The MSVC branch locally (no LLVM with MSVC detection on this PC); it is the unchanged command, which CI's Windows job runs.
• Linux skips this check, as before.

Related: #2240 (the other test that fails only with llvm-mingw).