Note that we use <stddef.h> instead of <cstddef> because we're
using size_t (not std::size_t) and we're outside of namespace std.
Differential Revision: https://reviews.llvm.org/D138716
Per our policy, the latest released AppleClang has been 14 for a while,
so libc++ is removing support for AppleClang 13. Our CI bots have been
moved to AppleClang 14 a few weeks ago.
Differential Revision: https://reviews.llvm.org/D138685
When we define the const-correct overloads of <string.h> functions in
libc++ itself, use builtins whenever possible. This avoids depending on
the presence of these functions in the C library headers.
Also, as a fly-by, improve the tests for these functions since we
basically didn't check anything but their signature. We could have
used the wrong builtin (as long as the signature matched) without ever
noticing, which was quite scary.
Differential Revision: https://reviews.llvm.org/D138684
The paper doesn't include anything affecting the library. AFAICT there isn't even anything to do for the compiler, since it just reserved the std attribute namespace.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D138128
This patch removes the base template implementation for std::char_traits.
If my reading of http://eel.is/c++draft/char.traits is correct, the
Standard mandates that the library provides specializations for several
types like char and wchar_t, but not any implementation in the base
template. Indeed, such an implementation is bound to be incorrect for
most types anyways, since things like `eof()` and `int_type` will definitely
have to be customized.
Since the base template implementation should not have worked for anyone,
this shouldn't be a breaking change (I expect that anyone defining a
custom character type today will already have to provide their own
specialization of char_traits). However, since we're aware of some users
of char_traits for unsigned char and signed char, we're keeping those two
specializations around for two releases to give people some time to migrate.
Differential Revision: https://reviews.llvm.org/D138307
This makes the library consistent in how it handles C library headers. For C headers provided by libc++,
we unconditionally include <foo.h> from <cfoo>, and then <foo.h> conditionally include_next <foo.h>.
For headers not provided by libc++, <cfoo> conditionally includes the system's <foo.h> directly.
Differential Revision: https://reviews.llvm.org/D138512
The ctype mask for newlib/picolibc is fully saturated, so __regex_word
has to overlap with one of the values. This commit uses the same workaround
as bionic did (uint16_t for char_class_type inside regex_traits). It
should be possible to have libc++ provide the default rune table instead,
but that will require a new mechanism to detect newlib inside __config
since the header defining the newlib/picolibc macros has not been included
yet inside __config. Doing it this way also avoids duplicating the ctype
table for newlib, reducing the global data size.
Differential Revision: https://reviews.llvm.org/D138195
Looks like std::conditional wasn't included in 14d4869209cc8ff9a53aaa5a59d6409fbc1c5f5d
(& maybe other typedefs that should be using this technique either got
missed or have regressed since that change was made)
This was noticed by a 1.4% clang.dwp regression due to
f4fb72e6d4cee1097e6606e66232fe55e793cd86 introducing more instantiations
of std::conditional - this change reduces that regression to 0.6% at
least.
I'm also looking at other instantiations caused by that change that
might be able to be addressed - but a quick grep shows ~200 "type"
typedefs missing _LIBCPP_NODEBUG, so maybe a systematic application of
the typedef might be suitable?
Differential Revision: https://reviews.llvm.org/D131082
The lowercase `__ppc64__` is not defined by non-darwin powerpc64 GCC, therefore
it lures users to write code which is not portable to GCC. Migrate to
`__powerpc64__` in preparation for undefining `__ppc64__`. `__powerpc64__` is
much more common than `__PPC64__`.
Update alignment_of.pass.cpp to use 1 unconditionally:
on powerpc-unknown-linux-gnu `alignof(bool) = _Alignof(bool) = __alignof(bool) = 1`.
The value 4 might be derived from an ancient Clang.
Change is_iec559 to true when long double uses uses IEEE 754 quadruple or double
precision (i.e. not ibm128).
Reviewed By: #libc, thesamesam, ldionne
Differential Revision: https://reviews.llvm.org/D137513
All supported compilers support the builtins, so this removes dead code and simplifies a lot of the functions through that.
Reviewed By: ldionne, #libc, EricWF
Spies: EricWF, michaelplatings, libcxx-commits
Differential Revision: https://reviews.llvm.org/D135781
The Standard specifies which types are stored in the basic_format_arg
"variant" and which types are stored as a handle. Libc++ stores
additional types in the "variant". During a reflector discussion
@jwakely mention this is user observable; visit_format_arg uses the type
instead of a handle as argument.
This optimization is useful and will probably be used for other small
types in the future. To be conferment the visitor creates a handle and
uses that as argument. There is a second visitor so the formatter can
still directly access the 128-bit integrals.
The test for the visitor and get has been made public too, there is no
reason not too. The 128-bit integral types are required by the Standard,
when they are available.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D138052
Buildkite doesn't provide a way to list bot owners so currently
we are pinging people on Discord and Phabricator.
Which works ok until that person is on vacation. This file gives us
a place to list multiple people, or group contacts for each bot.
I've stuck to the CODE_OWNERS.txt format because there's no great
reason to change it.
Reviewed By: #libc, EricWF, ldionne
Differential Revision: https://reviews.llvm.org/D138445
This makes it possible for programmers to run IWYU and get more accurate
standard library inclusions. Prior to this commit, the following program
would be transformed thusly:
```cpp
// Before
#include <algorithm>
#include <vector>
void f() {
auto v = std::vector{0, 1};
std::find(std::ranges::begin(v), std::ranges::end(v), 0);
}
```
```cpp
// After
#include <__algorithm/find.h>
#include <__ranges/access.h>
#include <vector>
...
```
There are two ways to fix this issue: to use [comment pragmas](https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUPragmas.md)
on every private include, or to write a canonical [mapping file](https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUMappings.md)
that provides the tool with a manual on how libc++ is laid out. Due to
the complexity of libc++, this commit opts for the latter, to maximise
correctness and minimise developer burden.
To mimimise developer updates to the file, it makes use of wildcards
that match everything within listed subdirectories. A script has also
been added to ensure that the mapping is always fresh in CI, and makes
the process a single step.
Finally, documentation has been added to inform users that IWYU is
supported, and what they need to do in order to leverage the mapping
file.
Closes#56937.
Differential Revision: https://reviews.llvm.org/D138189
GCC expands the pointer type in this conditional expression even for
template types _Up that are not arrays. This raises an error when
std::decay<> is used with reference types (as is done in LLVM's
sources). Using add_pointer<> causes GCC to only instantiate a
pointer type for array types.
Reviewed By: #libc, philnik, ldionne
Differential Revision: https://reviews.llvm.org/D135469
This is just to make to follow-up diffs simpler
Reviewed By: ldionne, #libc, EricWF
Spies: EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D137498
We currently call a lot of functions with the same list of types. To avoid forgetting any of them, this patch adds type_lists and utilities for it. Specifically, it adds
- `type_list` - This is just a list of types
- `concatenate` - This allows concatenating type_lists
- `for_each` - Iterate over a type_list
Reviewed By: ldionne, #libc
Spies: jloser, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D137476
Libc++ tried accomodating systems that need to be able to define various
__need_FOO macros before including C library headers, however it does not
appear to be needed anymore in most cases. Indeed, glibc used to use that
system to conditionally provide definitions, however almost all instances
of these macros have been removed from glibc years ago.
I think the next step would be to also fix Clang's own builtin headers
to stop needing these macros.
Differential Revision: https://reviews.llvm.org/D131425
This allows porting the library to platforms that are able to support
<iostream> but that do not have a notion of a filesystem, and where it
hence doesn't make sense to support std::fstream (and never will).
Also, remove reliance on <fstream> in various tests that didn't
actually need it.
Differential Revision: https://reviews.llvm.org/D138327
This allows discard_block_engine to work on platforms that might not
provide a full <limits.h> header.
Differential Revision: https://reviews.llvm.org/D138212
Some platforms don't provide all C library headers. In practice, libc++
only requires a few C library headers to exist, and only a few functions
on those headers. Missing functions that libc++ doesn't need for its own
implementation are handled properly by the using_if_exists attribute,
however a missing header is currently a hard error when we try to
do #include_next.
This patch should make libc++ more flexible on platforms that do not
provide C headers that libc++ doesn't actually require for its own
implementation. The only downside is that it may move some errors from
the #include_next point to later in the compilation if we actually try
to use something that isn't provided, which could be somewhat confusing.
However, these errors should be caught by folks trying to port libc++
over to a new platform (when running the libc++ test suite), not by end
users.
NOTE: This is a reapplicaton of 226409, which was reverted in 674729813
because it broke the build. The issue has now been fixed with
https://reviews.llvm.org/D138062.
Differential Revision: https://reviews.llvm.org/D136683
This prepares the terrain for introducing a new type of bounded iterator
that can't be constructed like __wrap_iter. This reverts part of the
changes made to std::vector in 4eab04f84.
Differential Revision: https://reviews.llvm.org/D138036
