This applies clang-format to the std::string unit tests in preparation
for landing https://reviews.llvm.org/D140550.

Differential Revision: https://reviews.llvm.org/D140612

Reviewed By: ldionne, #libc, #libc_abi

Spies: #libc_vendors, smeenai, libcxx-commits

Differential Revision: https://reviews.llvm.org/D145320

For some reason `operator""s(const char8_t*, size_t)` was marked `noexcept`. Remove it and add regression tests.

Reviewed By: ldionne, huixie90, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D132340

Many tests in `libcxx/test/std/strings` use
`#if defined(__cpp_lib_char8_t) && __cpp_lib_char8_t >= 201811L`
which can be replaced with the more terse `#ifndef TEST_HAS_NO_CHAR8_T`.

Differential Revision: https://reviews.llvm.org/D132626

Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.

Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.

Differential Revision: https://reviews.llvm.org/D111265

Even if these comments have a benefit in .h files (for editors that
care about language but can't be configured to treat .h as C++ code),
they certainly have no benefit for files with the .cpp extension.

Discussed in D110794.

Differential Revision: https://reviews.llvm.org/D109120

C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
just slightly confusing, but provides no value. It's similar to allowing
both std=c++17 and std=c++1z, which we don't do.

This was discovered because we had an internal bot that ran the test
suite under both c++98 AND c++03 -- one of which is redundant.

Differential Revision: https://reviews.llvm.org/D80926

By renaming .fail.cpp tests that don't need clang-verify to .compile.fail.cpp,
the new test format will not try to compile these tests with clang-verify,
and the old test format will work just the same. However, this allows
removing a workaround that requires parsing each test looking for
clang-verify markup.

After this change, a .fail.cpp test should always have clang-verify markup.
When clang-verify is not supported by the compiler, we will just check that
these tests fail to compile. When clang-verify is supported, these tests
will be compiled with clang-verify whether they have markup or not (so
they should have markup, or they will fail).

This simplifies the test suite and also ensures that all of our .fail.cpp
tests provide clang-verify markup. If it's impossible for a test to have
clang-verify markup, it can be moved to a .compile.fail.cpp test, which
are unconditionally just checked for compilation failure.

llvm-svn: 362252