Update LLVM

[fsb4000]

Updates the reference for the STL's llvm-project submodule. Doing so necessitates changes to:

• basic_string::resize_and_overwrite to enable a libc++ test to pass
• pointer_traits::pointer_to so "fancy pointers" work with constexpr basic_string (LWG-3454)
• Additions and removals to the expected_results.txt and skipped_tests.txt files that control the external and internal libc++ test runners
• Remove the workaround for LLVM-53957 which has been fixed
• Sync P0088R3_variant, P0220R1_any, and P220R1_optional tests with their upstream libc++ sources

Drive-by:

• sync tests/std/tests/P0088R3_variant/env.lst with usual_17_matrix.lst

Dual of MSVC-PR-428240.

[frederick-vs-ja]

I've investigated a few count of failed cases.
It seems that some case should have passed according to godbolt. I don't know what's going wrong.

[fsb4000]

What do we do when libc++ tests fail/pass on ARM but pass/fail on AMD64? Do we mark them SKIPPED?

And yes, I have read P0088R3_variant, P0220R1_any, P0220R1_optional tests and I will update them later.

[StephanTLavavej]

What do we do when libc++ tests fail/pass on ARM but pass/fail on AMD64? Do we mark them SKIPPED?

Yeah - currently we don't have a way to do per-architecture FAILs.

[frederick-vs-ja]

This test fails for 32-bit platforms because of truncation from (unsigned) long long to 32-bit size_t. Perhaps we can and should fix the libc++ test by using static_cast.

• std/numerics/rand/rand.dist/rand.dist.samp/rand.dist.samp.discrete/eval.pass.cpp

This test seemly fails for ARM/ARM64 platforms because MSVC STL considers tinyness_before to be always false even for ARM, but libc++ considers it to be true for floating-point types on ARM. I don't know which is right.

• std/language.support/support.limits/limits/numeric.limits.members/tinyness_before.pass.cpp

Currently we may have to skip tests with difference results on difference architectures.

[fsb4000]

I created https://reviews.llvm.org/D130963

[cpplearner]

I made a non-exhaustive analysis.

[strega-nil-ms]

This all looks very reasonable

[strega-nil-ms]

does c++latest not imply /permissive- for clang?

[CaseyCarter]

AFAIK /permissive- is meaningless for clang and cl /BE. I'm only touching this file to sync it back up with usual_17_matrix like the comment says, I don't intend to make any other changes.

That said, we need to make a pass over the env lists one of these days to remove /permissive and /permissive- where they are the defaults and/or meaningless.

[fsb4000]

clang understands /permissive and /permissive- since clang 13: llvm/llvm-project@c70b0e8

[CaseyCarter]

I'm not sure what if anything /Zc:twoPhase- means to clang-cl, since it doesn't accept my test case:

namespace N {
    struct S {};
}

template <class T>
constexpr bool f(T) {
    return true;
}

template <class T>
constexpr bool g(T x) {
    return f(x);
}

constexpr bool f(N::S) {
    return false;
}

static_assert(!g(N::S{}), "");

I'm unable to determine if /std:c++20 and /std:c++latest imply /permissive-.

[strega-nil-ms]

@CaseyCarter should this now be ready to merge, given that tests pass?

[CaseyCarter]

@CaseyCarter should this now be ready to merge, given that tests pass?

No, I'm still doing internal testing. (There are a couple classes of test cases that the GitHub test runner knows how to handle which the internal libcxx test runner does not. They need to be SKIPPED manually and aren't always easily detectible.) I'll move this to Final Review when it's green internally and externally.

[CaseyCarter]

Thanks so much for picking this up and finishing it off after I got busy, @fsb4000! Also thanks to everyone who helped analyze failures and classify issues.