Update llvm-project and toolset: MSVC Compiler 19.50.35719

[StephanTLavavej]

Fixes #5898. Fixes #5899.

Commits

• Automate check_libcxx_paths.py.
  • This script checks whether all paths mentioned in tests/libcxx/expected_results.txt actually exist, because nothing else in the GitHub/Python test harness will complain. (As I recall, we did teach the MSVC-internal test harness to complain.) Previously, running this script was a manual step that I had to remember to perform when updating the LLVM submodule. Now we can automate it for all local/PR/CI builds.
• Update llvm-project.
• Remove FAILs after:
  • [libc++] Remove obsolete locale-specific regex tests llvm/llvm-project#159590
  • [libc++][test] Make deallocate_size.pass.cpp MSVC-friendly llvm/llvm-project#165162
  • [libc++][test] Guard non-guaranteed implicit-lifetime-ness cases with _LIBCPP_VERSION llvm/llvm-project#160627
  • [libc++] Fix LLVM 22 TODOs llvm/llvm-project#153367
• Remove FAILs after MSVC Compiler 19.50.35718.
  • DevCom-10026599 VSO-1532879 "conditional expression has two different types" has apparently been fixed; I've asked @Codiferous to confirm.
• Add FAILs after a new test emitting MSVC truncation warnings was added by:
  • [libc++] Optimize ofstream::write llvm/llvm-project#123337
• Add SKIPPED for more "technically flaky" tests.
• Cycle locations, add comments.
• Add/extract commented-out tests.
  • This makes it easy to sort the active tests, and reminds us why GH_000639_nvcc_include_all isn't listed.
• Rename to P0896R4_and_P1614R2_comparisons so sorted order doesn't depend on case sensitivity.
  • I'm otherwise ignoring case-sensitive issues (e.g. I am not attempting to detect duplicates with different cases).
• Improve check_libcxx_paths.py.
  • This uses list comprehensions to simplify control flow.
  • Extract config_rgx so its usage is less visually busy.
  • Use sorted() to make it clearer that we want to print nonexistent tests in sorted order. (We don't care about the list's contents afterwards.)
  • Use the VSO syntax so that validation failures are displayed directly in the UI, instead of just general configuration failure.
• Add and run check_test_lst_paths.py.
  • I probably spent way too much time on this, but now I won't have to complain about missing edits to test.lst.
  • Instead of just checking for test directory existence, I consider only nonempty directories to be relevant. This is much like git's own behavior. (I'm intentionally not looking for any particular files within the directories.)
  • This uniformly handles std and tr1. (Technically commented_tests should be used only for std but it's harmless for tr1 unless someone's trying to be wacky.)
  • I consider it important to gather and report all failures, since reporting just one failure is extremely annoying to iterate through. (However, I report only the first occurrence of unsortedness, since there may be zillions, and fixing that is easy.)
  • Note that if multiple test directories are damaged, configuration will complain only about the first one in order (libcxx, std, tr1). Although this doesn't follow my "report all failures" principle, avoiding this wasn't worth the effort, and damaging multiple directories simultaneously is unlikely.
• Cleanup display names.
  • This makes them less verbose, especially because Azure Pipelines tends to display them in a narrow column.
• Invert polarity: skipTesting => runTesting
  • The negative sense of this parameter was confusing. Now, runTesting controls whether run-tests.yml does anything.
• Add a 'Configure Tests' stage.
  • Checking libcxx's validity requires the llvm-project submodule to be checked out, and it's a chonky kitty. The early builds previously didn't need llvm-project, so adding it to the critical path would increase overall test latency.
  • CMakeLists.txt
    • Nothing used or mentioned BUILD_TESTING. Rename it to CONFIGURE_TESTING because that's what it controls (and "build testing" was very confusing, given all of the options we have to control how much testing happens).
  • cmake-configure-build.yml
    • Take configureTesting and buildStl parameters. Pass the former as CONFIGURE_TESTING, and use the latter to control whether we build the STL (previously, no stage skipped building the STL, except for Code Format which uses an entirely different YAML.)
  • build-and-test.yml
    • Take configureTesting and buildStl, defaulting to true.
    • Use configureTesting to control whether we checkout the llvm-project submodule.
    • Pass the parameters down to cmake-configure-build.yml.
  • azure-pipelines.yml
    • The early builds now pass configureTesting: false, to avoid slowing down the critical path as previously mentioned.
    • Add a new 'Configure Tests' stage. This is x64-only (arch-specific configuration failures for the tests subdirectory seem unlikely, and will of course be caught by the full test passes). It looks like the early builds, except that it passes buildStl: false (and implicitly leaves configureTesting as true). It also doesn't bother passing any options relating to builds (we don't care about building with /analyze, and we don't want to build the benchmarks). The time we save building the STL can then be spent on syncing llvm-project.
    • Make Test_x64 depend on Configure_Tests. As usual, the other full test passes fan out from this.
• MSVC Compiler 19.50.35719.
• New pools.
• Mark C++26 tests as FAIL for the MSVC-internal test harness.

Automating check_libcxx_paths.py

• tests/CMakeLists.txt
  • Find Python immediately, so it's available when we add_subdirectory(libcxx).
• tests/libcxx/CMakeLists.txt
  • Run check_libcxx_paths.py, and if it fails, make configuring fail.
• tools/scripts/check_libcxx_paths.py
  • Extract expected_results_txt.
  • If we fail, print expected_results_txt to clearly indicate which file needs to be fixed.
  • Print failures to stderr so they're clearly distinguished from normal CMake output (e.g. if it's being redirected).
  • Success is silence.

Failure Examples

Failure looks like this:

When configuring:

D:\GitHub\STL>cmake --preset x64
-- The CXX compiler identification is MSVC 19.50.35718.0
[...]
-- Found Python: C:/Users/stl/AppData/Local/Programs/Python/Python314/python.exe (found suitable version "3.14.0", minimum required is "3.14.0") found components: Interpreter
Failure: tests/libcxx/expected_results.txt contains 8 nonexistent tests:
std/re/re.alg/re.alg.match/awk.locale.pass.cpp
std/re/re.alg/re.alg.match/basic.locale.pass.cpp
std/re/re.alg/re.alg.match/ecma.locale.pass.cpp
std/re/re.alg/re.alg.match/extended.locale.pass.cpp
std/re/re.alg/re.alg.search/awk.locale.pass.cpp
std/re/re.alg/re.alg.search/basic.locale.pass.cpp
std/re/re.alg/re.alg.search/ecma.locale.pass.cpp
std/re/re.alg/re.alg.search/extended.locale.pass.cpp
##vso[task.logissue type=error]tests/libcxx/expected_results.txt failed validation, see log.
CMake Error at tests/libcxx/CMakeLists.txt:4 (execute_process):
  execute_process failed command indexes:

    1: "Child return code: 1"



-- Configuring incomplete, errors occurred!

When directly run:

D:\GitHub\STL>py tools\scripts\check_test_lst_paths.py tests\std
Failure: tests\std\test.lst contains 2 duplicate tests:
tests\Dev11_0272959_make_signed
tests\Dev11_0535636_functional_overhaul
Failure: tests\std\test.lst is missing 2 tests:
tests\Dev11_0671816_list_splice
tests\GH_003617_vectorized_meow_element
Failure: tests\std\test.lst contains 1 nonexistent tests:
tests\GH_009999_future_technology
Failure: tests\std\test.lst isn't sorted, starting with:
tests\P2417R2_constexpr_bitset
##vso[task.logissue type=error]tests\std\test.lst failed validation, see log.

[zacklj89]

Not blocking: I think this won't normalize paths. It probably doesn't matter here, but we could use resolve instead?

[StephanTLavavej]

We have existing usage in other scripts; I'll investigate this for a potential followup. Thanks!

[zacklj89]

Not blocking: This and below is mixing uses of strings and Path objects I think. We could standardize on Paths?

[StephanTLavavej]

This was at least partially intentional since Paths insist on being printed with backslashes and I didn't see any way to request forward slashes (like with <filesystem>'s generic_string()). I agree it's somewhat confusing though.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[StephanTLavavej]

I had to push an additional commit to mark C++26 tests as FAIL for the MSVC-internal test harness.