[Gonic0]

What

core/libs/tests/write_watch/CMakeLists.txt registers the execute-fault and read-fault write watch tests twice: #12117 (eb20686c42) and #12435 (1f1da4b0ff) each added the same foreach(mode execute-fault read-fault) block, and both are on main. The directory is added only on macOS (if(APPLE) in core/libs/CMakeLists.txt), so on macOS with tests enabled CMake stops while configuring:

CMake Error at core/libs/tests/write_watch/CMakeLists.txt:42 (add_test):
  add_test given test NAME "write_watch_execute-fault" which already exists
  in this directory.

and the same for write_watch_read-fault, which also blocks every build in that tree. This removes the second block. Linux and Windows do not add the directory and are unaffected.

Tested

Apple M5 Pro, macOS 27.2, x86-64 Release under Rosetta 2. main alone does not build on macOS; I configured and built in a tree with the open macOS port PRs merged with today's main, where the file is identical to this branch's.

• Before: reconfiguring with BUILD_TESTING=ON fails with the error above.
• After: CMake configures, write_watch_tests and write_watch_backing_tests build, and ctest -R '^write_watch_' passes 18 of 18, with write_watch_execute-fault and write_watch_read-fault listed once each.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Fixes: none
• Unblocks: configuring a macOS build with tests on main
• GPUs tested: none (build and test registration only)
• AI-assisted: yes

🤖 Generated with Claude Code

[JJenkx]

Supplementary current-main configuration repro and CI impact for exact head e9f09f54fabb6408d3e2711b8df10c10112ab00e.

Main 381891927c2b3ff494a9853cb79fde8d5342b92d still fails cmake -S core/libs/tests/write_watch -B build/write-watch -DCMAKE_BUILD_TYPE=Release with duplicate write_watch_execute-fault / write_watch_read-fault names. A private clean merge of this PR (3aa7d2ff4012c8fbecb89e51d441afe6673b3117) configures successfully and generates 18 unique test registrations, with both fault cases present exactly once.

This also explains the red write-watch checks on the approved math PRs #10113, macOS Intel job and #10226, macOS ARM job: both stop at this same CMake error before testing the math implementation. Their source branches remain unchanged.

My check ran on Linux and covers configuration/test registration only. A standalone build reaches the expected platform limit (mach/mach.h is unavailable here); I claim no runtime or macOS execution pass. The existing Mac execution reports above remain the runtime evidence.

Main/fix configuration logs, generated-registration list, public patch and build limitation — SHA-256 baa6846cd077f72afb1270bdc26a9923e2f32990cb983de7c627ee0b9c5bc4bb. AI-assisted: yes (Codex).

[JJenkx]

Thanks for merging this on November1. Several owned PRs still show older macOS write-watch failures from before the merge. I inspected #12122's macos-15 job: configuration stops because write_watch_execute-fault and write_watch_read-fault are registered twice. It did not reach compilation or runtime tests.

Please initiate fresh qualification against current main for the affected unchanged heads (#13119, #12598, #12592, #12514, #12122, #12053, #10345, #10328, #10325, #10321, #10234, #10229, #10226 and #9688). I have not treated the old failures as passes or assumed that every failure has the same cause. The three branches freshly rebased in this pass have new CI runs and are excluded from this list. My upstream access cannot initiate the required job reruns.

The separate Windows guest_set_env assertion on #12871 is still under an acknowledged main/PR baseline investigation, not classified as this configure issue or as flaky. AI-assisted: yes.