[release/9.0-staging] Add flags when the clang's major version is > 20.0

[AaronRobinsonMSFT]

Customer Impact

• Customer reported
• Found internally

These issues were reported in #119706 as problems with clang-21 on Fedora 43. The investigation uncovered that clang introduced a potentially breaking change in clang-20 that we do not currently consume. These build changes impact VMR related builds when linux distrobutions performing source build adopt clang-21.

clang-20 breaking change log - https://releases.llvm.org/20.1.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes.

This PR contains the minimal changes needed to fix issues from the following PR #120775.

.NET 10: #121124
.NET 8: #121150

Regression

• Yes
• No

Build with the new clang-21 compiler will cause the runtime to crash.

Testing

This has been validated using various legs and examples to demonstrate the usage of undefined behavior these flags convert into "defined" behavior in C/C++.

Risk

Low. This has zero impact on our production build since we specifically target clang-18. This is only valid for those partners that are using clang-20+.

[dotnet-policy-service]

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull Request Overview

This PR updates compiler flags for Clang version 20 and above on Unix hosts. When Clang 20+ is detected, it switches from using -fwrapv to using -fno-strict-overflow (which implies -fwrapv and -fwrapv-pointer in Clang 20+) and also adds -fno-strict-aliasing to match MSVC behavior.

Key changes:

• Adds version detection for Clang 20.0 and above
• Uses -fno-strict-overflow and -fno-strict-aliasing for Clang 20+
• Maintains existing -fwrapv flag for older compiler versions

[jkotas]

Does this need to include the fix for the debugger build break as well?

cc @tmds

[jkoritzinsky]

Any concern here about Clang on macOS? If so, this should use MATCHES instead of STREQUAL.

[tmds]

This is missing the CorDebugUserState change (which is a compiler error and not a warning):

di/rspriv.h:6357:36: error: in-class initializer for static data member is not a constant expression
       6357 |     static const CorDebugUserState kInvalidUserState = CorDebugUserState(-1);

[tmds]

Does this need to include the fix for the debugger build break as well?

We should fix anything that is in dotnet/dotnet that ends up in the distro's DOTNET_ROOT.

It's not needed to fix sources that Microsoft compiles (with clang < 21) and ships through nuget.org.