[libc++] Make parameter names consistent and enforce the naming style using readability-identifier-naming

Ensure that parameter names have the style `__lower_case`

Reviewed By: ldionne, #libc

Spie

[libc++] Make parameter names consistent and enforce the naming style using readability-identifier-naming

Ensure that parameter names have the style `__lower_case`

Reviewed By: ldionne, #libc

Spies: aheejin, sstefan1, libcxx-commits, miyuki

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

show more ...

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604,
and 489637e66dd3. This should cover almost all the includes that had
been removed since LLVM 14 and that would contribute to breaking user
code when releasing LLVM 15.

It is possible to disable the inclusion of these headers by defining
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will
enable that macro and start fixing downstream issues immediately. We
can then remove the macro (and the transitive includes) by default in
a future release. That way, we will break users only once by removing
transitive includes in bulk instead of doing it bit by bit a every
release, which is more disruptive for users.

Note 1: The set of headers to re-add was found by re-generating the
transitive include test on a checkout of release/14.x, which
provided the list of all transitive includes we used to provide.

Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map>
have been added in this commit. These transitive inclusions were
added when we implemented boyer_moore_searcher in <functional>.

Note 3: This is a best effort patch to try and resolve downstream breakage
caused since branching LLVM 14. I wasn't able to perfectly mirror
transitive includes in LLVM 14 for a few headers, so I added a
release note explaining it. To summarize, adding boyer_moore_searcher
created a bunch of circular dependencies, so we have to break
backwards compatibility in a few cases.

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

show more ...

[libc++] Granularize <iterator> includes

Reviewed By: ldionne, #libc

Spies: libcxx-commits, wenlei

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

[libc++] Add various missing _LIBCPP_HIDE_FROM_ABI

Those were spotted when a project unintentionally started exporting
these symbols from its ABI just by using the libc++ headers.

Differential Revi

[libc++] Add various missing _LIBCPP_HIDE_FROM_ABI

Those were spotted when a project unintentionally started exporting
these symbols from its ABI just by using the libc++ headers.

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

show more ...

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any publ

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.

It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.

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

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++] Granularize <utility> includes

Reviewed By: ldionne, #libc

Spies: EricWF, libcxx-commits, arphaman

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

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

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

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

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

show more ...

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste st

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.

show more ...

[libcxx][modularisation] moves <utility> content out of <type_traits>

Moves:

* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges`

[libcxx][modularisation] moves <utility> content out of <type_traits>

Moves:

* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
`__algorithm/${FUNCTION_NAME}`

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

show more ...

[libc++] Alphabetize and include-what-you-use. NFCI.

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

[libc++] Include <__config> first in all standard headers.

Mostly, *don't* include <experimental/__config> from C++17 <any>,
because that doesn't make any sense. I think it was just a cut-and-paste

[libc++] Include <__config> first in all standard headers.

Mostly, *don't* include <experimental/__config> from C++17 <any>,
because that doesn't make any sense. I think it was just a cut-and-paste
typo when this header moved from experimental/.

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

show more ...

[libc++] Rework the whole availability markup implementation

Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the header

[libc++] Rework the whole availability markup implementation

Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the headers
will by default prevent you from using some features that were not
released in the dylib on your target platform. This is a source of
frustration since people building libc++ from sources are usually not
trying to use some vendor's released dylib.

For that reason, I've been thinking for a long time that availability
annotations should be off by default, which is the primary change that
this commit enables.

In addition, it reworks the implementation to make it easier for new
vendors to add availability annotations for their platform, and it
refreshes the documentation to reflect the current state of the codebase.

Finally, a CMake configuration option is added to control whether
availability annotations should be turned on for the flavor of libc++
being created. The intent is for vendors like Apple to turn it on, and
for the upstream libc++ to leave it off (the default).

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

show more ...

[libc++] Fix failures when running the test suite without RTTI

[libc++] Use allocator_traits to consistently allocate/deallocate/construct/destroy objects in std::any

https://llvm.org/PR45099 notes (correctly) that we're inconsistent in memory
allocation in `st

[libc++] Use allocator_traits to consistently allocate/deallocate/construct/destroy objects in std::any

https://llvm.org/PR45099 notes (correctly) that we're inconsistent in memory
allocation in `std::any`. We allocate memory with `std::allocator<T>::allocate`,
construct with placement new, destroy by calling the destructor directly, and
deallocate by calling `delete`. Most of those are customizable by the user,
but in different ways.

The standard is silent on how these things are to be accomplished.
This patch makes it so we use `allocator_traits<allocator<T>>` for all
of these operations (allocate, construct, destruct, deallocate).
This is, at least, consistent.

Fixes https://llvm.org/PR45099.

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

show more ...

[NFC][libc++] Remove stray semi-colon after function definition

llvm-svn: 363835

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[libcxx] Add availability markup for bad_optional_access, bad_variant_access and bad_any_cast

Reviewers: dexonsmith, EricWF

Subscribers: christof, arphaman, libcxx-commits

Differential Revision: h

[libcxx] Add availability markup for bad_optional_access, bad_variant_access and bad_any_cast

Reviewers: dexonsmith, EricWF

Subscribers: christof, arphaman, libcxx-commits

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

llvm-svn: 347219

show more ...

Implement the infrastructure for feature-test macros. Very few actual feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955

llvm-svn: 342073

[NFC][libc++] Consistently use spaces to indent

rdar://problem/19988944

llvm-svn: 338933

[libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY

Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually

[libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY

Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.

This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.

Note that this commit had originally been applied in r336369 and then
reverted in r336382 because of unforeseen problems. Both of these problems
have now been fixed.

Reviewers: EricWF, mclow.lists

Subscribers: christof, dexonsmith, erikvanderpoel

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

llvm-svn: 336866

show more ...

Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY"

This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE

Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY"

This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of
_LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the
dylib and the check-cxx-abilist failing.

2. The LLDB tests started failing because they undefine
`_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and
fix the tests before we can go forward with this change.

llvm-svn: 336382

show more ...

[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY

Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempt

[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY

Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.

This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.

Reviewers: EricWF

Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists

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

llvm-svn: 336369

show more ...

Implement part of LWG#2857 - any/optional. Still to do - variant. Reviewed as https://reviews.llvm.org/D31956

llvm-svn: 300123

[NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS

The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both
_LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to
__attribute__((__typ

[NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS

The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both
_LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to
__attribute__((__type_visibility__)) with Clang. The only remaining difference
is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas
_LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on
templates).

This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS.

llvm-svn: 291035

show more ...