Toolset update: MSVC Compiler 19.50.35702, test <filesystem> long path support by StephanTLavavej · Pull Request #5783 · microsoft/STL (original) (raw)

Changelog

• Improved test coverage:
  • Added test coverage for <filesystem>'s long path support.
• Code cleanups:
  • Removed compiler bug workarounds.
• Infrastructure improvements:
  • Updated dependencies.
    * Updated MSVC Compiler to 19.50.35702 (now required).
    * Updated CMake to 4.1.1 (now required).
    * Updated Python to 3.14.0 (now required).
    * Updated Boost.Math to 1.89.0.

Overview

In this toolset update, I attempted to add an ARM64 pool. While I encountered roadblocks and abandoned the attempt for now,
I was able to extend provision-image.ps1 to automatically detect when it's being run in an ARM64 VM, and switch to ARM64 installers. I also have small restructurings to create-1es-hosted-pool.ps1 that will make it easier to add ARM64 as an option in the future.

I was also able to enable long paths in the VMs, and write a test to exercise one of <filesystem>'s functions. It's written
to detect the absence of long path support and do nothing, so it won't break local test runs.

Commits

• Azure extended the deadline for default outbound access.
• Extract $PoolSize.
  • Because ARM64 will use a smaller pool.
• Centralize StlBuild, use double quotes instead of plus concat.
  • Making it easier for everything to mention the arch.
• Improve log name, put arch in resource group name.
  • This is a significant improvement for the log files (previously, we'd concat to an existing log file). I'm shrinking "StlBuild" to just "Stl" since "Build" adds nothing, and I'm adding the arch which makes things longer.
• PowerShell 7.5.3.
• Python 3.14.0.
  • I now require the specific patch version we've upgraded to (or later). No reason to let people get away with outdated dependencies, even slightly.
• Extend provision-image.ps1 to detect ARM64.
  • Manually verified. This was actually quite easy; we don't need to pass parameters, since the script can just look at the machine architecture. ARM64 builds are available for all of our dependencies except CUDA, which we simply skip.
  • The one headache was that I encountered a failure to immediately delete the installer, presumably because the ARM64 VM was somewhat slower (I only had access to v5 for manual testing, not v6). This is potentially an issue for x64 too, we just haven't encountered yet. I felt that a 5-second sleep was the simplest way to avoid this.
• MSVC Compiler 19.50.35702.
  • I am no longer attempting to name Insiders releases of the compiler in the error message.
• CMake 4.1.1.
  • Again, requiring the specific patch version (or newer).
• Set CMAKE_MSVC_RUNTIME_CHECKS to the empty string.
  • This was added in CMake 4.0: https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_RUNTIME_CHECKS.html
  • We clear out all of CMake's default options before setting our own.
  • Fixes: cl : Command line error D8016 : '/RTC1' and '/O2' command-line options are incompatible
  • This matches internal src/vctools/crt/crt_build.settings.targets, which sets <NoRtc>true</NoRtc>.
• CMakeLists.txt: Update comment to no longer mention "MSVC version 19.32.31328".
• Boost.Math 1.89.0.
  • I will replace this with an MSVC-internal commit, already tested.
• special_math.cpp: Silence warning C4714: function marked as __forceinline not inlined.
• VSO_0744055_atomic_load_8_bytes_readonly: Update comment to no longer mention "MSVC 19.24".
• Overhaul VSO_0744055_atomic_load_8_bytes_readonly.
  • Don't printf(), instead assert() to check correctness.
  • Cite documentation explaining why the bytes are 0.
  • Use std::uint64_t instead of unsigned long long for clarity.
  • There's no need to static_cast<unsigned char*> the result of MapViewOfFileEx.
  • Use std::align() as I don't see any documented alignment guarantees.
• Skip flaky libcxx test to resolve libcxx: Flaky timing assumption in std/thread/thread.semaphore/timed.pass.cpp #5733.
• Remove workarounds for VSO-1008447, VSO-2066340.
• Enable long paths to resolve : Consider setting up the 1ES Hosted Pool with long path support for test coverage #1923.
• Extract test_temp_directory with minor changes:
  • Make directoryPath a const data member. (It probably should be private with an accessor, but that required too many changes for my level of laziness.)
  • Add qualification.
  • Use std::endl as I am slightly paranoid about flushing output for logs.
  • If we can't create the temp directory, assert instead of simply warning. This will block further testing.
• Add GH_001923_filesystem_long_path_support.
  • We need custom_format.py to link against Advapi32.lib, but especially to pass /MANIFESTINPUT:{manifestFile}. The Python script can get the path to long_path_aware.manifest which lives next to test.cpp. Attempting to do this through PM_LINK in env.lst won't work, because the compile-and-link step is run in a subdirectory (and I felt that hardcoding .. was gross).
• Extract $Provisioning_x64, for clarity.
• Use Get-AzContext to avoid annoying warnings.
  • Set-AzContext was emitting an annoying warning about an apparently inaccessible unrelated "tenant". After logging in, the subscription appears to stay fixed to CPP_STL_GitHub, so we just need a check that we're using the right subscription. I now also print a clear message if the check fails. (Connect-AzAccount pops up a UI dialog, so I don't want to automatically run it.)
• New pool.

STL-ASan-CI passed.