📜 Changelog

• Code cleanups:
  • Removed compiler bug workarounds.
• Infrastructure improvements:
  • Updated dependencies.
    • Updated build compiler to VS 2022 17.14.5 Preview 1.
    • Updated Python to 3.13.4.
    • Updated to Windows 11 SDK 26100. This is now required for building and testing the STL, but not for using it.

💡 Notes

• Followup to Update source_location tests for upcoming EDG changes #5551. EDG's output for x86 was slightly different than what we expected, so I'm adjusting the test accordingly. Again, once this updated EDG ships, I'll be able to clean up the test to expect the new output only; right now it's accepting either new or old.
• The MSVC-internal toolset was finally updated, picking up the compiler bugfix for C++23 static lambdas being rejected by the old lambda processor. However, attempting to activate static lambdas for MSVC revealed an issue affecting basic_format_arg::handle's constructor (unrelated to the old lambda processor). Apparently we're storing a function pointer here for type erasure purposes (I don't really understand this myself, but we can't change the representation of this C++20 class now), but creating that function pointer with a lambda is not necessary. After looking at the lambda, I decided that I didn't like it, so I'm changing to a static member function template (which should be equally good for type erasure).
  • In Toolset update: VS 2022 17.14.5 Preview 1, WinSDK 26100 #5580 (comment), @voroncae figured out that the issue with the lambda was that static lambdas aren't omniconvertible to custom calling conventions. We absolutely need explicit __cdecl to avoid ODR violations, so that's another reason to use a function template.
• Followup to Build tests for ARM64EC pipeline #5521. It had to work around several WinSDK issues, solved by updating the WinSDK. I'm updating both the PR/CI system, and our requirements for maintainers/contributors building locally. However, the MSVC-internal build is still stuck on the older WinSDK for tedious and hopefully temporary reasons. I've added a TRANSITION comment about this. We can survive the divergence because we (surprisingly) don't have STL test coverage for ARM64EC internally. Any new issues caused by WinSDK divergence will be discovered during mirroring, which is a minor potential time-waster for me, but I don't anticipate issues occurring before the divergence can be eliminated.
• The new WinSDK doesn't support ARM32, so I'm commenting out the stages in Azure Pipelines. Full removal is coming in a followup PR. (Yes, commented-out code is bad and should feel bad; this is highly temporary as a reminder to myself that I need to properly purge all mentions.)

⚙️ Commits

• Python 3.13.4.
• VS 2022 17.14.5 Preview 1.
• Windows 11 SDK (10.0.26100.3916).
• New pool.
• Update P1208R6_source_location for EDG again.
• VERIFIED INTERNALLY: Remove workaround for VSO-2417635 "/clr C++20 chk assertion failed: rhs.is_lvalue() in constexpr.cpp, again".
• VERIFIED INTERNALLY: Remove workaround for VSO-1168721 "Assertion failed: p.edges.size() <= 1 comparing converted pointer in constant expression".
• VERIFIED: Remove workaround for VSO-2383148 "C++23 static lambdas aren't accepted by the old lambda processor".
• Change a lambda in basic_format_arg::handle's constructor to a function template.
• VERIFIED: Remove WinSDK ARM64EC workarounds for fabsf.
• VERIFIED: Update WinSDK comments as warnings C6553 and C28301 still repro.
• azure-pipelines.yml: Comment out Early_Build_ARM, Build_And_Test_ARM.
• Comment out the Early_Build_ARM dependency too.