[libc++] Remove the allocator<const T> extension (#96319)

This effort has quite a history:
- This was first attempted in 2022 via bed3240bf7d1, which broke
std::shared_ptr<T const> and caused the

[libc++] Remove the allocator<const T> extension (#96319)

This effort has quite a history:
- This was first attempted in 2022 via bed3240bf7d1, which broke
std::shared_ptr<T const> and caused the change to be reverted in
9138666f5464.
- We then re-attempted landing the change in 276ca87382b8 after fixing
std::shared_ptr, but reports were made that this broke code en masse
within Google. This led to the patch being reverted again in
a54d028895c9 with the goal to land this again with a migration path for
vendors.

This patch re-lands the removal while providing a migration path for
vendors by providing the `_LIBCPP_ENABLE_REMOVED_ALLOCATOR_CONST` macro.
This macro will be honored for the LLVM 19 release and will be removed
after that, at which point allocator<const T> will be removed
unconditionally.

Fixes #73665

show more ...

[libc++] Fix constexpr initialization of std::array<T, 0> (#74667)

This patch fixes constexpr default initialization of empty arrays and
improves the tests accordingly.

Fixes #74375

[libc++][test] Enhance ADDITIONAL_COMPILE_FLAGS, use TEST_MEOW_DIAGNOSTIC_IGNORED sparingly (#75317)

This is the last PR that's needed (for now) to get libc++'s tests
working with MSVC's STL.

Th

[libc++][test] Enhance ADDITIONAL_COMPILE_FLAGS, use TEST_MEOW_DIAGNOSTIC_IGNORED sparingly (#75317)

This is the last PR that's needed (for now) to get libc++'s tests
working with MSVC's STL.

The ADDITIONAL_COMPILE_FLAGS machinery is very useful, but also very
problematic for MSVC, as it doesn't understand most of Clang's compiler
options. We've been dealing with this by simply marking anything that
uses ADDITIONAL_COMPILE_FLAGS as FAIL or SKIPPED, but that creates
significant gaps in test coverage.

Fortunately, ADDITIONAL_COMPILE_FLAGS also supports "features", which
can be slightly enhanced to send Clang-compatible and MSVC-compatible
options to the right compilers.

This patch adds the gcc-style-warnings and cl-style-warnings Lit features,
and uses that to pass the appropriate warning flags to tests. It also uses
TEST_MEOW_DIAGNOSTIC_IGNORED for a few local suppressions of MSVC
warnings.

show more ...

[libc++] Remove unnecessary main() function in .compile.pass.cpp and .verify.cpp tests

We pretty consistently don't define those cause they are not needed,
and it removes the potential pitfall to th

[libc++] Remove unnecessary main() function in .compile.pass.cpp and .verify.cpp tests

We pretty consistently don't define those cause they are not needed,
and it removes the potential pitfall to think that these tests are
being run. This doesn't touch .compile.fail.cpp tests since those
should be replaced by .verify.cpp tests anyway, and there would be
a lot to fix up.

As a fly-by, I also fixed a bit of formatting, removed a few unused
includes and made some very minor, clearly NFC refactorings such as
in allocator.traits/allocator.traits.members/allocate.verify.cpp where
the old test basically made no sense the way it was written.

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

show more ...

[libc++] Define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER whenever we enable warnings in the test suite

This should make CI consistent on all the compilers we support. Most of
this patch is working around

[libc++] Define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER whenever we enable warnings in the test suite

This should make CI consistent on all the compilers we support. Most of
this patch is working around various warnings emitted by GCC in our code
base, which are now being shown when we compile the tests.

After this patch, the whole test suite should be warning free on all
compilers we support and test, except for a few warnings on GCC that
we silence explicitly until we figure out the proper fix for them.

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

show more ...

[libc++] Replace _LIBCPP_HAS_NO_CONCEPTS with _LIBCPP_STD_VER > 17. NFCI.

All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBC

[libc++] Replace _LIBCPP_HAS_NO_CONCEPTS with _LIBCPP_STD_VER > 17. NFCI.

All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.

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

show more ...

Revert "[libc++] Remove extension to support allocator<const T>"

This reverts commit 276ca873. That commit has quite a history at this
point. It was first landed in dbc647643577, which broke std::sh

Revert "[libc++] Remove extension to support allocator<const T>"

This reverts commit 276ca873. That commit has quite a history at this
point. It was first landed in dbc647643577, which broke std::shared_ptr<T const>
and was reverted in 9138666f5. It was then re-applied in 276ca873, with
the std::shared_ptr issue fixed, but it caused widespread breakage at
Google (which suggests it would cause similar breakage in the wild too),
so now I'm reverting again.

Instead, I will add a escape hatch that vendors can turn on to enable
the extension and perform a phased transition over one or two releases
like we sometimes do when things become non-trivial.

show more ...

[libc++] Remove extension to support allocator<const T>

This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
imple

[libc++] Remove extension to support allocator<const T>

This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.

This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.

This is a re-application of dbc647643577, which was reverted in 9138666f5
because it broke std::shared_ptr<T const>. Tests have now been added and
we've made sure that std::shared_ptr<T const> wouldn't be broken in this
version.

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

show more ...

Revert "[libc++] Remove extension to support allocator<const T>"

This reverts commit bed3240bf7d196a17cc31f1c5b59b4721017e638.

I will need to add more tests for std::shared_ptr<T const> before
re-l

Revert "[libc++] Remove extension to support allocator<const T>"

This reverts commit bed3240bf7d196a17cc31f1c5b59b4721017e638.

I will need to add more tests for std::shared_ptr<T const> before
re-landing this.

show more ...

[libc++] Remove extension to support allocator<const T>

This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
imple

[libc++] Remove extension to support allocator<const T>

This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.

This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.

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

show more ...

[libc++] Add an option to disable wide character support in libc++

Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It

[libc++] Add an option to disable wide character support in libc++

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

show more ...

[libc++] Disallow volatile types in std::allocator

LWG 2447 is marked as `Complete`, but there is no `static_assert` to
reject volatile types in `std::allocator`. See the discussion at
https://revie

[libc++] Disallow volatile types in std::allocator

LWG 2447 is marked as `Complete`, but there is no `static_assert` to
reject volatile types in `std::allocator`. See the discussion at
https://reviews.llvm.org/D108856.

Add `static_assert` in `std::allocator` to disallow volatile types. Since this
is an implementation choice, mark the binding test as `libc++` only.

Remove tests that use containers backed by `std::allocator` that test
the container when used with a volatile type.

Reviewed By: ldionne, #libc

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

show more ...

[libcxx] rearranges all concept tests

moves tests into directories matching their stable names so that the
tests can reflect the concept name

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