| Age | Commit message (Collapse) | Author |
|---|
|
This simplifies the code quite a bit and seems to improve code size
slightly in some cases.
|
|
_LIBCPP_HIDE_FROM_ABI everywhere (#131156)" (#141756)
This reverts commit c861fe8a71e64f3d2108c58147e7375cd9314521.
Unfortunately, this use of hidden visibility attributes causes
user-defined specializations of standard-library types to also be marked
hidden by default, which is incorrect. See discussion thread on #131156.
...and also reverts the follow-up commits:
Revert "[libc++] Add explicit ABI annotations to functions from the block runtime declared in <__functional/function.h> (#140592)"
This reverts commit 3e4c9dc299c35155934688184319d391b298fff7.
Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)"
This reverts commit f73287e623a6c2e4a3485832bc3e10860cd26eb5.
Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)"
This reverts commit 1d411f27c769a32cb22ce50b9dc4421e34fd40dd.
|
|
_LIBCPP_HIDE_FROM_ABI everywhere (#131156)
This patch introduces `_LIBCPP_{BEGIN,END}_EXPLICIT_ABI_ANNOTATIONS`,
which allow us to have implicit annotations for most functions, and just
where it's not "hide_from_abi everything" we add explicit annotations.
This allows us to drop the `_LIBCPP_HIDE_FROM_ABI` macro from most
functions in libc++.
|
|
The need for `_LIBCPP_TEMPLATE_VIS` has been removed in #133233.
|
|
Add a `valid-element-access` check to `valarray::operator[]` and
`bitset::operator[]`.
|
|
This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the
RFC, we initially proposed selecting the right headers from the Clang
driver, however consensus seemed to steer towards handling this in the
library itself. This patch implements that direction.
At a high level, the changes basically amount to making each public
header look like this:
```
// inside <vector>
#ifdef _LIBCPP_CXX03_LANG
# include <__cxx03/vector>
#else
// normal <vector> content
#endif
```
In most cases, public headers are simple umbrella headers so there isn't
much code in the #else branch. In other cases, the #else branch contains
the actual implementation of the header.
|
|
|
|
Including The frozen C++03 headers results in a lot of formatting
changes in the main headers, so this splits these changes into a
separate commit instead.
This is part of
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.
|
|
|
|
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `<__configuration/availability.h>` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.
The current patch only touches the macros defined in `<__config>`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `<__config_site>`.
|
|
As time went by, a few files have become mis-formatted w.r.t.
clang-format. This was made worse by the fact that formatting was not
being enforced in extensionless headers. This commit simply brings all
of libcxx/include in-line with clang-format again.
We might have to do this from time to time as we update our clang-format
version, but frankly this is really low effort now that we've formatted
everything once.
|
|
Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
that mechanism anymore, we don't need to declare __libcpp_verbose_abort
from all public headers, and we can clean up a lot of unnecessary
includes.
This patch also moves the definition of the various assertion categories
to the <__assert> header, since we now rely on regular IWYU for these
assertion macros.
rdar://105510916
|
|
Those appear to be oversights when committing patches
in the last few months.
|
|
The valarray<>::operator[](...) const functions return proxy objects.
The valarray<>::operator[](...) functions return valarray objects.
However the standard allows functions returning valarray objects to
return custom proxy objects instead. Libc++ returns __val_expr proxies.
Functions taking a valarray object must work with the custom proxies
too. Therefore several operations have a custom proxy overload instead
of valarray overloads.
Libc++ doesn't specify a valarray overload. This is an issue with the
standard proxy types; these can implicitly be converted to a valarray.
The solution is to allow the standard proxies to behave as-if they are
custom proxies.
This patch fixes the valarray compound assignments. Other operations,
like the binary non-member functions are not fixed. These will be done
in a followup patch.
Fixes: https://github.com/llvm/llvm-project/issues/21320
|
|
This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.
This patch was generated with:
find libcxx/include libcxx/src -type f \
| grep -v 'module.modulemap.in' \
| grep -v 'CMakeLists.txt' \
| grep -v 'README.txt' \
| grep -v 'libcxx.imp' \
| grep -v '__config_site.in' \
| xargs clang-format -i
A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.
[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
|
|
As part of the upcoming clang-formatting of libc++, this patch performs
the long desired removal of the _VSTD macro.
See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.
|
|
In preparation for running clang-format on the whole code base, we are
also removing mentions of the legacy _LIBCPP_INLINE_VISIBILITY macro in
favor of the newer _LIBCPP_HIDE_FROM_ABI.
We're still leaving the definition of _LIBCPP_INLINE_VISIBILITY to avoid
creating needless breakage in case some older patches are checked-in
with mentions of the old macro. After we branch for LLVM 18, we can do
another pass to clean up remaining uses of the macro that might have
gotten introduced by mistake (if any) and remove the macro itself at the
same time. This is just a minor convenience to smooth out the transition
as much as possible.
See
https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.
|
|
This brings most of the enable_ifs in libc++ to the same style. It also has the nice side-effect of reducing the size of names of these symbols, since the depedent return type is shorter.
Reviewed By: #libc, ldionne
Spies: ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D157736
|
|
into _LIBCPP_EXPORTED_FROM_ABI
These macros are always defined identically, so we can simplify the code a bit by merging them.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, krytarowski, smeenai
Differential Revision: https://reviews.llvm.org/D152652
|
|
Implements parts of P1614R2:
- Added `operator==` to `slice`
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D152617
|
|
Reviewed By: ldionne, #libc
Spies: libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D149599
|
|
There is no type named sliceExpr, so it's likely a misspelling of
either slice_array or __slice_expr. Neither of which appear to
need the friend declaration.
This may indicate a unimplemented bit of `<valarray`, but ¯\_(ツ)_/¯
Nobody uses it anyway.
(Commit message provided by @EricWF.)
This reverts commit e13c43b229527234ec99f7f03aff3e1560c259c8.
|
|
This reverts commit d5193e34b81fb3e9c27aea541516112d8a5f708d.
Reverted at @EricWF's request so it can be relanded with a better commit
message.
|
|
The class is never defined. This was discovered while validating modules
in libc++.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D148357
|
|
We changed the `abort` calls when trying to throw exceptions in `-fno-exceptions` mode to `__verbose_abort` calls, which removes the dependency in most files.
Reviewed By: ldionne, #libc
Spies: dim, emaste, mikhail.ramalho, smeenai, libcxx-commits
Differential Revision: https://reviews.llvm.org/D146076
|
|
This avoids instantiating lots of types.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D146984
|
|
This patch also updates the moved code to the new style (i.e. formatted, replaced marcos and typedefs)
Reviewed By: ldionne, #libc
Spies: arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D145095
|
|
Other macros that disable parts of the library are named `_LIBCPP_HAS_NO_WHATEVER`.
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits, smeenai
Differential Revision: https://reviews.llvm.org/D143163
|
|
This change is almost fully mechanical. The only interesting change is in `generate_feature_test_macro_components.py` to generate `_LIBCPP_STD_VER >=` instead. To avoid churn in the git-blame this commit should be added to the `.git-blame-ignore-revs` once committed.
Reviewed By: ldionne, var-const, #libc
Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei
Differential Revision: https://reviews.llvm.org/D143962
|
|
Reviewed By: Mordante, #libc
Spies: libcxx-commits, wenlei
Differential Revision: https://reviews.llvm.org/D140673
|
|
This reverts commit a6e1080b87db8fbe0e1afadd96af5a3c0bd5e279.
Fix the conditions when the `memmove` optimization can be applied and refactor them out into a reusable type trait, fix and significantly expand the tests.
Differential Revision: https://reviews.llvm.org/D139235
|
|
Reviewed By: #libc, ldionne
Spies: jwakely, beanz, smeenai, cfe-commits, tschuett, avogelsgesang, Mordante, sstefan1, libcxx-commits, ldionne, mgorny, arichardson, miyuki
Differential Revision: https://reviews.llvm.org/D131963
|
|
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D140480
|
|
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D137283
|
|
Breaks msan, asan
https://lab.llvm.org/buildbot/#/builders/5/builds/27904
This reverts commit 005916de58f73aa5c4264c084ba7b0e21040d88f.
|
|
Instead of using `reverse_iterator`, share the optimization between the 4 algorithms. The key observation here that `memmove` applies to both `copy` and `move` identically, and to their `_backward` versions very similarly. All algorithms now follow the same pattern along the lines of:
```
if constexpr (can_memmove<InIter, OutIter>) {
memmove(first, last, out);
} else {
naive_implementation(first, last, out);
}
```
A follow-up will delete `unconstrained_reverse_iterator`.
This patch removes duplication and divergence between `std::copy`, `std::move` and `std::move_backward`. It also improves testing:
- the test for whether the optimization is used only applied to `std::copy` and, more importantly, was essentially a no-op because it would still pass if the optimization was not used;
- there were no tests to make sure the optimization is not used when the effect would be visible.
Differential Revision: https://reviews.llvm.org/D130695
|
|
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D134447
|
|
Use `using` aliases to avoid instantiating lots of types
Reviewed By: ldionne, #libc
Spies: libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D132785
|
|
As discussed in D132284 they will be moved to the end.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D133212
|
|
This defines a new policy for removal of transitive includes.
The goal of the policy it to make it relatively easy to remove
headers when needed, but avoid breaking developers using and
vendors shipping libc++.
The method used is to guard transitive includes based on the
C++ language version. For the upcoming C++23 we can remove
headers when we want, but for other language versions we try
to keep it to a minimum.
In this code the transitive include of `<chrono>` is removed
since D128577 introduces a header cycle between `<format>`
and `<chrono>`. This cycle is indirectly required by the
Standard. Our cycle dependency tool basically is a grep based
tool, so it needs some hints to ignore cycles. With the input
of our transitive include tests we can create a better tool.
However that's out of the scope of this patch.
Note the flag `_LIBCPP_REMOVE_TRANSITIVE_INCLUDES` remains
unchanged. So users can still opt-out of transitives includes
entirely.
Reviewed By: #libc, ldionne, philnik
Differential Revision: https://reviews.llvm.org/D132284
|
|
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
|
|
Reviewed By: ldionne, Mordante, #libc, saugustine
Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman
Differential Revision: https://reviews.llvm.org/D127953
|
|
The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for
slightly different configurations (like the debug mode or assertions
in the dylib) are taken into account. That results in unexpected bugs
like http://llvm.org/PR50534 (and there have been multiple similar
bugs in the past, notably around the debug mode).
This patch gets rid of the _LIBCPP_DISABLE_EXTERN_TEMPLATE knob, which
I don't think is fundamental. Indeed, the motivation for that knob was to
avoid taking a dependency on the library, however that can be done better
by linking against the static library instead. And in fact, some parts of
the headers will always depend on things defined in the library, which
defeats the original goal of _LIBCPP_DISABLE_EXTERN_TEMPLATE.
Differential Revision: https://reviews.llvm.org/D103960
|
|
Currently, unary expressions involving valarray will create a temporary.
This leads to dangling references in expressions like `-a * b`, because
`-a` is a temporary and the resulting expression will refer to it. This
patch fixes the problem by creating a lazy expression to perform the unary
operation instead of eagerly creating a temporary valarray. This is
permitted by the Standard, which does not specify the exact type of
most expressions involving valarrays.
This is technically an ABI break, however I believe the actual potential
for breakage is very low.
rdar://90152242
Differential Revision: https://reviews.llvm.org/D125019
|
|
Reviewed By: var-const, #libc, ldionne
Spies: #libc_vendors, ldionne, libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D124123
|
|
Reviewed By: Mordante, #libc
Spies: libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D123912
|
|
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
|
|
This fixes instances of the newly added `-Wunqualified-std-cast-call`.
(Commit 7853371146 removed unqualified `move` from the tests,
but these unqualified `move`s remained undetected in the actual headers.)
Differential Revision: https://reviews.llvm.org/D120509
|
|
Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi
Spies: #libc_vendors, libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D119667
|
|
Now we'll notice if a header forgets to include this magic phrase.
Differential Revision: https://reviews.llvm.org/D118800
|
