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
Formatting the alternate form for the general categories should keep the
trailing zeros. This was reported by @fsb4000 in D131336.
The default format uses general formatting but this should not keep the
trailing zeros so the default format is not passed to the formatter.
While testing I found an off by one error; finding the exponent character
`e` in 1e+03 will start at after the `1` so a size of `4` can contain an
exponent.
Reviewed By: fsb4000, ldionne, #libc
Differential Revision: https://reviews.llvm.org/D131417
Move the concept to the concepts header and uses a name in the style of
P2286.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D131176
Implements:
- LWG3721 Allow an arg-id with a value of zero for width in std-format-spec
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D130649
While working on D132534 it appeared the experimental PMR code doesn't
have version guards and fails to compile on C++03. This adds the guards
for that version. It seems the tests already were only disabled for
C++03.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D132582
This version is build without support for the experimental library but
the code still wants to link this function. Inlining the function solves
the issue.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D132667
This patch simplifies the implementation of `deque` by removing the `__deque_base` class which results in a lot less indirections and removes the need for `__base::`.
Reviewed By: ldionne, #libc
Spies: AdvenamTacet, libcxx-commits
Differential Revision: https://reviews.llvm.org/D132081
libc++ prior to LLVM 15 has a bug in it due to it excluding
`remove_reference_t` when `__remove_reference` is available as a
compiler built-in. This went unnoticed until D116203 because it wasn't
available in any compiler.
To work around this, we're renaming `__remove_reference` to
`__remove_reference_t`.
TEST=Tested locally, tested using emscripten
This was discussed on Discord with the consensus that we should rename the macros.
Reviewed By: ldionne, Mordante, var-const, avogelsgesang, jloser, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D131498
When we ship LLVM 16, <ranges> won't be considered experimental anymore.
We might as well do this sooner rather than later.
Differential Revision: https://reviews.llvm.org/D132151
_HAS_EXCEPTIONS=0 allows disabling the exception parts of the MS STL
and vcruntime, and e.g. compiler-rt/lib/fuzzer sets this define (to
work around issues with MS STL). If using libc++ instead of MS STL,
this define previously broke the libc++ headers.
If _HAS_EXCEPTIONS is set to 0, the vcruntime_exception.h header
doesn't define the ABI base class std::exception. If no exceptions
are going to be thrown, this probably is fine (although it also
breaks using subclasses of it as regular objects that aren't thrown),
but it requires ifdeffing out all subclasses of all exception/error
derived objects (which are sprinkled throughout the headers).
Instead, libc++ will supply an ABI compatible definition when
_HAS_EXCEPTIONS is set to 0, which will make the class hierarchies
complete.
In this build configuration, one can still create instances of
exception subclasses, and those objects will be ABI incompatible
with the ones from when _HAS_EXCEPTIONS isn't defined to 0 - but
one may argue that's a pathological/self-imposed problem in that case.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103947
An issue I often see in codebases compiled for unusual platforms is
that header search paths are specified manually and are subtly wrong.
For example, people will manually add `-isystem <some-toolchain>/usr/include`,
which ends up messing up the layering of header search paths required by
libc++ (because the C Standard Library now appears *before* libc++ in
the search paths). Without this patch, this will end up causing
compilation errors that are pretty inscrutable. This patch aims to
improve the user experience by diagnosing this issue explicitly.
In all cases I can think of, I would expect that a compilation error
occur if these header search paths are not layered properly. This
should only provide an explicit diagnostic instead of failing due
to seemingly unrelated compilation errors.
Differential Revision: https://reviews.llvm.org/D131441
While working on D129964 I noticed some code hadn't been uglyfied, this
rectifies the issue.
Depends on D129964
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D131834
The new operator<=> is mapped onto the existing functions
__libcpp_thread_id_equal and __libcpp_thread_id_less. Introducing a
new __libcpp_thread_id_compare_three_way might lead to more efficient
code. Given that we can still introduce __libcpp_thread_id_compare_three_way
later, for this commit I opted to not break ABI. If requested, I will
add __libcpp_thread_id_compare_three_way in a follow-up commit.
Implements part of P1614R2 "The Mothership has Landed"
Differential Revision: https://reviews.llvm.org/D131362
Also, add missing tests for assertions in span constructors. Now I
believe that all of std::span's API should be hardened, and all the
assertions should have a corresponding test.
Differential Revision: https://reviews.llvm.org/D131681
While implementing `operator<=>` for `string_view` (D130295) @philnik
pointed out `common_type` should be `type_identity`. Since it was an
existing issue that wasn't addressed.
This addresses the issue for both the new and existing equality and
comparison operators. The test is based on the example posted in
D130295.
Reviewed By: philnik, #libc, huixie90
Differential Revision: https://reviews.llvm.org/D131322
D131234 marked the ranges papers as complete, but it didn't set the
feature-test macro.
Reviewed By: ldionne, var-const, #libc
Differential Revision: https://reviews.llvm.org/D131326
When back-deploying to older platforms, we can still provide assertions,
but we might not be able to provide a great implementation for the verbose
handler. Instead, we can just call ::abort().
Differential Revision: https://reviews.llvm.org/D131199
Evaluating `contiguous_iterator` on an iterator that satisfies all the
constraints except the `to_address` constraint and doesn't have
`operator->` defined results in a hard error. This is because
instantiating `to_address` ends up instantiating templates
dependent on the given type which might lead to a hard error even
in a SFINAE context.
Differential Revision: https://reviews.llvm.org/D130835
Also fix `ranges::stable_sort` and `ranges::inplace_merge` to support
proxy iterators now that their internal implementations can correctly
dispatch `rotate`.
Differential Revision: https://reviews.llvm.org/D130758
The return value for both of these algorithms is specified as
```
`{last, result - N}` for the overloads in namespace `ranges`.
```
But the current implementation instead returns `{first, result - N}`.
Also add both algorithms to the relevant "robust" tests.
Differential Revision: https://reviews.llvm.org/D130968
This paper was accepted during the last plenary and is intended to be
backported to LLVM 15. When backporting the release notes in the branch
should be updated too.
Note the feature-test macro isn't updated since this will change; three
papers have updated the same macro in the same plenary.
Implements:
- P2508R1 Exposing std::basic-format-string
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D130643
This improves the formatting of the generated files. That allows it to
remove the clang-format step in D129668.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D130911
The macro is only enabled when the Clang is used with
-fexperimental-library.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D130792
I went over the output of the following mess of a command:
`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Reviewed By: #libc, philnik
Spies: philnik, libcxx-commits, mgorny, arichardson
Differential Revision: https://reviews.llvm.org/D130905
With the goal of reusing that handler to do other things besides
handling assertions (such as terminating when an exception is thrown
under -fno-exceptions), the name `__libcpp_assertion_handler` doesn't
really make sense anymore.
Furthermore, I didn't want to use the name `__libcpp_abort_handler`,
since that would give the impression that the handler is called
whenever `std::abort()` is called, which is not the case at all.
Differential Revision: https://reviews.llvm.org/D130562
Summary:
The AIX linker does not merge typeinfos when shared libraries are involved, which causes address comparison to fail although the types are the same. This patch changes to use the non-unique implementation for typeinfo comparison for AIX.
Reviewed by: hubert.reinterpretcast, philnik, libc++
Differential Revision: https://reviews.llvm.org/D130715
Avoid relying on `iterator_traits` and instead deduce the return type of
dereferencing the iterator. Additionally, add a static check to reject
iterators with incorrect `iterator_traits` at compile time.
Differential Revision: https://reviews.llvm.org/D130538
Since the calendar is added in C++20 the existing operators are removed.
Implements part of:
- P1614R2 The Mothership has Landed
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D129887
- for all algorithms taking more than one range, add a `robust` test to
check the case where the ranges have different value types and the
given projections are different, with each projection applying to
a different value type;
- fix `ranges::include` to apply the correct projection to each range.
Differential Revision: https://reviews.llvm.org/D130515
Instead of taking a fixed set of arguments, use variadics so that
we can pass arbitrary arguments to the handler. This is the first
step towards using the handler to handle other non-assertion-related
failures, like std::unreachable and an exception being thrown in
-fno-exceptions mode, which would improve user experience by including
additional information in crashes (right now, we call abort() without
additional information).
Differential Revision: https://reviews.llvm.org/D130507
This adds a C++20-version of `reverse_iterator` which doesn't SFINAE away the operators for use inside the classic STL algorithms. Pre-C++20 `_AlgRevIter` is just an alias for `reverse_iterator`.
Reviewed By: var-const, #libc
Spies: huixie90, libcxx-commits
Differential Revision: https://reviews.llvm.org/D128864
When -fexperimental-library is passed, libc++ will now pick up the
appropriate __has_feature flag defined by Clang to enable the
experimental library features.
As a fly-by, also update the documentation for the various TSes.
Differential Revision: https://reviews.llvm.org/D130176
In D125283, we ensured that integer distributions would not compile when
used with arbitrary unsupported types. This effectively enforced what
the Standard mentions here: http://eel.is/c++draft/rand#req.genl-1.5.
However, this also had the effect of breaking some users that were
using integer distributions with unsupported types like int8_t. Since we
already support using __int128_t in those distributions, it is reasonable
to also support smaller types like int8_t and its unsigned variant. This
commit implements that, adds tests and documents the extension. Note that
we voluntarily don't add support for instantiating these distributions
with bool and char, since those are not integer types. However, it is
trivial to replace uses of these random distributions on char using int8_t.
It is also interesting to note that in the process of adding tests
for smaller types, I discovered that our distributions sometimes don't
provide as faithful a distribution when instantiated with smaller types,
so I had to relax a couple of tests. In particular, we do a really bad
job at implementing the negative binomial, geometric and poisson distributions
for small types. I think this all boils down to the algorithm we use in
std::poisson_distribution, however I am running out of time to investigate
that and changing the algorithm would be an ABI break (which might be
reasonable).
As part of this patch, I also added a mitigation for a very likely
integer overflow bug we were hitting in our tests in negative_binomial_distribution.
I also filed http://llvm.org/PR56656 to track fixing the problematic
distributions with int8_t and uint8_t.
Supersedes D125283.
Differential Revision: https://reviews.llvm.org/D126823
Mark de Wever