You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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).
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.
The reason will be displayed to describe this comment to others. Learn more.
Left a question, but otherwise LGTM. @StephanTLavavej - lmk if you need help load balancing the creation of the compiler bugs and other bits you mentioned in the PR you did not have bandwidth for, I may be able to assist (/ I ought to be able, so this can be a forcing function :-P )
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📜 Changelog
đź’ˇ Notes
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.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).__cdecl
to avoid ODR violations, so that's another reason to use a function template.⚙️ Commits
p.edges.size() <= 1
comparing converted pointer in constant expression".basic_format_arg::handle
's constructor to a function template.