Mark LWG3447 as complete since it was not an issue since the original
implementation of `take_view` from
0f4b41e038. Currently, `take_view`'s
deduction guide does not constrain the range on the `range` concept.
Reviewed By: ldionne, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111501
Implement P2401 which adds a `noexcept` specification to
`std::exchange`. Treated as a defect fix which is the motivation for
applying this change to all standards mode rather than just C++23 or
later as the paper suggests.
Reviewed By: Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111481
Implement P2251 which requires `span` and `basic_string_view` to be
trivially copyable. They already are - this just adds tests to bind that
behavior.
Reviewed By: ldionne, Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111197
Due to reported failures in a local build.
FAIL: Something is wrong in the test framework.
Converting character sets: Invalid argument.
(was enabled in https://reviews.llvm.org/D111138)
Replace `TEST_NOEXCEPT_FALSE` directly with `noexcept(false)` in
optional hash test which is only run in C++17 or later.
`TEST_NOEXCEPT_FALSE` is only useful in C++03 context where `noexcept`
isn't supported by clang. `TEST_NOEXCEPT_FALSE` now only has one remaining use
in `hash_unique_ptr.pass.cpp`.
There is an empty `namespace std` in `type_traits` which was originally
used when `std::byte` was added in
c97d8aa866. At some point, the bitwise operators
on `std::byte` got relocated but this empty namespace was left around.
Remove it.
Reviewed By: Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111512
Implement parts of P1614, including three-way comparison for tuples, and expand testing.
Reviewed By: ldionne, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D108250
Update the status with the approved papers and LWG-issues in the October 2021 plenary.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D111166
While looking at the review comments in D103765 there was an oddity in
the tests for the following functions:
- atomic_fetch_add
- atomic_fetch_add_explicit
- atomic_fetch_sub
- atomic_fetch_sub_explicit
Libc++ allows usage of
`atomic_fetch_add<int>(atomic<int*>*, atomic<int*>::difference_type);`
MSVC and GCC reject this code: https://godbolt.org/z/9d8WzohbE
This makes the atomic `fetch(add|sub).*` Standard conforming and removes the non-conforming extensions.
Fixes PR47908
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D103983
It is not used anywhere anymore since we're using the new runtimes build
in <monorepo>/runtimes now, so we can remove all traces of this build.
Differential Revision: https://reviews.llvm.org/D111351
When we recently started using DYLD_LIBRARY_PATH to run the test suite
on the Apple/System configuration of the library, the -fno-exceptions
variant started failing.
It started failing because under that configuration, libc++abi.dylib
doesn't provide support for exceptions. For example, it doesn't provide
some symbols such as ___gxx_personality_v0. Now, the problem is that
when the test suite is run with DYLD_LIBRARY_PATH, /usr/lib/libobjc.dylib
uses the just-built libc++abi.dylib, which doesn't support exceptions,
and we end up with an unresolved reference to ___gxx_personality_v0.
Previously, using -Wl,-rpath,path/to/lib, we would be loading both
/usr/lib/libc++abi.dylib and <just-built>/lib/libc++abi.dylib.
/usr/lib/libobjc.dylib would use the system libc++abi.dylib, which
contains support for exceptions, and the tests would be using the
just-built one, which doesn't.
Disentangling that led me to believe that we shouldn't try to test this
configuration where libc++/libc++abi are built as system libraries, but
where they don't support exceptions, since that just doesn't make any
sense. Doing so is like trying to build libc++/libc++abi and test it as
a system library after performing an ABI break -- of course nothing is
going to work.
For that reason, I am removing this configuration. Note that we could
still test the library on macOS without exceptions if we wanted, only
we wouldn't be building it as a system library. This patch doesn't add
that because we already have a -fno-exceptions CI job on Linux.
Differential Revision: https://reviews.llvm.org/D111349
Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.
In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.
The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.
But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.
This is a re-application of 9892d1644f, which was reverted in 138dc27186
because it broke the build. The issue was that we didn't apply the required
changes to libunwind and our CI didn't notice it because we were not
running the libunwind tests. This has been fixed now, and we're running
the libunwind tests in CI now too.
Differential Revision: https://reviews.llvm.org/D110736
Replace `&__rhs` with `_VSTD::addressof(__rhs)` to guard against ADL hijacking
of `operator&` in `operator=`. Thanks to @CaseyCarter for bringing it to our
attention.
Similar issues with hijacking `operator&` still exist, they will be
addressed separately.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D110852
Implements the formatter for Boolean types.
[format.formatter.spec]/2.3
For each charT, for each cv-unqualified arithmetic type ArithmeticT other
than char, wchar_t, char8_t, char16_t, or char32_t, a specialization
```
template<> struct formatter<ArithmeticT, charT>;
```
This removes the stub implemented in D96664.
Implements parts of:
- P0645 Text Formatting
- P1652 Printf corner cases in std::format
Completes:
- P1868 width: clarifying units of width and precision in std::format
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103670
Implements the formatter for all fundamental integer types.
[format.formatter.spec]/2.1
The specializations
```
template<> struct formatter<char, char>;
template<> struct formatter<char, wchar_t>;
template<> struct formatter<wchar_t, wchar_t>;
```
This removes the stub implemented in D96664.
Implements parts of:
- P0645 Text Formatting
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103466
Implements the formatter for all fundamental integer types
(except `char`, `wchar_t`, and `bool`).
[format.formatter.spec]/2.3
For each charT, for each cv-unqualified arithmetic type ArithmeticT other
than char, wchar_t, char8_t, char16_t, or char32_t, a specialization
```
template<> struct formatter<ArithmeticT, charT>;
```
This removes the stub implemented in D96664.
As an extension it adds partial support for 128-bit integer types.
Implements parts of:
- P0645 Text Formatting
- P1652 Printf corner cases in std::format
Completes:
- LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103433
Implements the formatter for all string types.
[format.formatter.spec]/2.2
For each charT, the string type specializations
```
template<> struct formatter<charT*, charT>;
template<> struct formatter<const charT*, charT>;
template<size_t N> struct formatter<const charT[N], charT>;
template<class traits, class Allocator>
struct formatter<basic_string<charT, traits, Allocator>, charT>;
template<class traits>
struct formatter<basic_string_view<charT, traits>, charT>;
```
This removes the stub implemented in D96664.
Implements parts of:
- P0645 Text Formatting
- P1868 width: clarifying units of width and precision in std::format
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103425
If you don't have ptrace permissions this test will fail to run
silently, this adds a check for that and anything else that
might do similar things.
The output will now be:
```
FAILED test program did not run correctly, check gdb warnings
/usr/bin/gdb: warning: Couldn't determine a path for the index cache
directory.
No symbol table is loaded. Use the "file" command.
warning: Error disabling address space randomization: Operation not
permitted
warning: Could not trace the inferior process.
warning: ptrace: Operation not permitted
error: command failed with exit status: 255
```
We already have a feature to check for a compatible python enabled
gdb, so I think it's reasonable to check for this at test runtime.
Note that this is different to the catch all at the end of the test
script. That would be a case where you can trace but something else
made it stop mid way that wasn't our test breakpoints.
Reviewed By: saugustine
Differential Revision: https://reviews.llvm.org/D110936
When the locale is not some UTF-8 these tests fail.
(different results for python2 linked gdbs vs. python3
but same issue)
Setting the locale just for the test works around this.
By default Ubuntu comes with just C.UTF-8. I've chosen
to use en_US.UTF-8 instead given that my Mac doesn't have
the former and there's a slim chance this test might run there.
This also enables the u16string tests which are now passing.
Reviewed By: #libc, ldionne, saugustine
Differential Revision: https://reviews.llvm.org/D111138
The unique (ha!) thing about this range type is that it's move-only.
Its contiguity is unsurprising (most of our test ranges are contiguous).
Discussed in D111231 but committed separately for clarity.
If you have a `begin() const` member, you don't need a `begin()` member
unless you want it to do something different (e.g. have a different return
type). So in general, //view// types don't need `begin()` non-const members.
Also, static_assert some things about the types in "types.h", so that we
don't accidentally break those properties under refactoring.
Differential Revision: https://reviews.llvm.org/D111231
Priorities below 101 are reserved for the implementation, so that's what
we should be using here. That is unfortunately only supported on more
recent versions of Clang. See https://reviews.llvm.org/D31413 for details.
Differential Revision: https://reviews.llvm.org/D95972
Reduce code duplication by sharing most of the test suite setup across
the different from-scratch configs.
Differential Revision: https://reviews.llvm.org/D111196
Implement P1391 (https://wg21.link/p1391) which allows
`std::string_view` to be constructible from any contiguous range of
characters.
Note that a different paper (http://wg21.link/P1989) handles the generic
range constructor for `std::string_view`.
Reviewed By: ldionne, Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D110718
We should arguably have always been doing that. The state of libunwind
is quite sad, so this commit adds several XFAILs to make the CI pass.
We need to investigate why so many tests are not passing in some
configurations, but I'll defer that to folks who actually work on
libunwind for lack of bandwidth.
Differential Revision: https://reviews.llvm.org/D110872
In basic_string and vector, we've been encapsulating all exception
throwing code paths in helper functions of a base class, which are defined
in the compiled library. For example, __vector_base_common defines two
methods, __throw_length_error() and __throw_out_of_range(), and the class
is externally instantiated in the library. This was done a long time ago,
but after investigating, I believe the goal of the current design was to:
1. Encapsulate the code to throw an exception (which is non-trivial) in
an externally-defined function so that the important code paths that
call it (e.g. vector::at) are free from that code. Basically, the
intent is for the "hot" code path to contain a single conditional jump
(based on checking the error condition) to an externally-defined function,
which handles all the exception-throwing business.
2. Avoid defining this exception-throwing function once per instantiation
of the class template. In other words, we want a single copy of
__throw_length_error even if we have vector<int>, vector<char>, etc.
3. Encapsulate the passing of the container-specific string (i.e. "vector"
and "basic_string") to the underlying exception-throwing function
so that object files don't contain those duplicated string literals.
For example, we'd like to have a single "vector" string literal for
passing to `std::__throw_length_error` in the library, instead of
having one per translation unit.
However, the way this is achieved right now has two problems:
- Using a base class and exporting it is really weird - I've been confused
about this ever since I first saw it. It's just a really unusual way of
achieving the above goals. Also, it's made even worse by the fact that
the definitions of __throw_length_error and __throw_out_of_range appear
in the headers despite always being intended to be defined in the compiled
library (via the extern template instantiation).
- We end up exporting those functions as weak symbols, which isn't great
for load times. Instead, it would be better to export those as strong
symbols from the library.
This patch fixes those issues while retaining ABI compatibility (e.g. we
still export the exact same symbols as before). Note that we need to
keep the base classes as-is to avoid breaking the ABI of someone who
might inherit from std::basic_string or std::vector.
Differential Revision: https://reviews.llvm.org/D111173
This is less brittle than hand-picking the substitutions that we
pass to the test, since a config could theorically use non-base
substitutions as well (such as defining %{flags} in terms of another
substitution like %{include}).
Also, print the decoded substitutions, which makes it much easier
to debug the test when it fails.
Differential Revision: https://reviews.llvm.org/D111179
Some tests repeat the definition of `DELETE_FUNCTION` macro locally.
However, it's not even requred to guard against in the C++03 case since
Clang supports `= delete;` in C++03 mode. A warning is issued but
`libc++` tests run with `-Wno-c++11-extensions`, so this isn't an issue.
Since we don't support other compilers in C++03 mode, `= delete;` is
always available for use. As such, inline all calls of `DELETE_FUNCTION`
to use `= delete;`.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D111148
This was missed in ec574f5da4. TIME_UTC
is a define that goes along with timespec_get. The testcase that it is
moved to is only run for >= C++17, so the surrounding ifdef guard
can be dropped.
Differential Revision: https://reviews.llvm.org/D110988
e9ee517930 added support for using
winpthreads on Windows, enabled if `__WINPTHREADS_VERSION` was
defined (i.e. if winpthreads headers have been included before
including libcxx `__config`). This was fragile (libcxx changed
behaviour depending on what headers had been included externally
before), and was changed in a1bc823a59
to use pthreads on Windows whenever the pthread.h header was
available.
This is also fragile; pthread.h might be unavailable while building
libcxx but installed later, and available when users include the
libcxx headers.
In practice, in every modern setup for building libcxx for Windows
I've seen, users end up manually configuring it with
`LIBCXX_HAS_WIN32_THREAD_API=ON`, as the users may have winpthreads
installed (for other libraries/projects to use) while wanting to
build libcxx with the default win32 threading.
Don't automatically pick up pthreads on Windows even if the header
is available. Instead require the user to configure the libcxx
build with `LIBCXX_HAS_PTHREAD_API=ON` if that's desired.
Differential Revision: https://reviews.llvm.org/D110975
This is to simplify an upcoming change where we distinguish between
flavors of libc++ by adding an apple-libc++ Lit feature.
Differential Revision: https://reviews.llvm.org/D110870
Joe Loser