Try checking for Darwin and Clang in addition to AppleClang

[jtschuster]

The build machines may have had some changes that cause this workaround to be more fragile. Try checkign for CMAKE_SYSTEM_NAME == "Darwin" AND CMAKE_CXX_COMPILER_ID == "Clang" in addition to CMAKE_CXX_COMPILER_ID == "AppleClang"

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Updates the native CMake compiler configuration to make the $<LINK_GROUP:RESCAN> no-op workaround less dependent on AppleClang detection, improving resiliency on Darwin build machines whose toolchains may report Clang instead.

Changes:

• Extend the $<LINK_GROUP:RESCAN> no-op enablement to also apply when CMAKE_SYSTEM_NAME == "Darwin" and CMAKE_CXX_COMPILER_ID == "Clang".
• Keep the existing AppleClang-specific logic for forcing the classic linker on Xcode 15.
• Minor whitespace cleanup in the Emscripten version mismatch warning block.

[jkotas]

The build machines may have had some changes

Where did the non-standard (?) clang version that got installed on the build machines come from?

[jkotas]

The new osx-x64 build failure is #104105

[jkotas]

Superseded by #125763