| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently std::mutex has a constexpr constructor, but a non-trivial
destruction.
The constexpr constructor is required to ensure the construction of a
mutex with static storage duration happens at compile time, during
constant initialization, and not during dynamic initialization.
This means that static mutex's are always initialized and can be used
safely during dynamic initialization without the "static initialization
order fiasco".
A trivial destructor is important for similar reasons. If a mutex is
used during dynamic initialization it might also be used during program
termination. If a static mutex has a non-trivial destructor it will be
invoked during termination. This can introduce the "static
deinitialization order fiasco".
Additionally, function-local statics emit a guard variable around
non-trivially destructible types. This results in horrible codegen and
adds a runtime cost to every call to that function. non-local static's
also result in slightly worse codegen but it's not as big of a problem.
Example codegen can be found here: https://goo.gl/3CSzbM
Note: This optimization is not safe with every pthread implementation.
Some implementations allocate on the first call to pthread_mutex_lock
and free the allocation in pthread_mutex_destroy.
Also, changing the triviality of the destructor is not an ABI break.
At least to the best of my knowledge :-)
llvm-svn: 365273
|
|
|
|
|
|
| |
bit of D58332. Thanks to Mikhail Maltsev for pointing this out
llvm-svn: 365261
|
|
|
|
|
|
| |
and iter_swap are updated (with tests).
llvm-svn: 365238
|
|
|
|
|
|
|
|
| |
happens to be there"
This reverts r365222, which broke the libc++ build bots.
llvm-svn: 365233
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
be there
Summary:
Otherwise, when libcxxabi is not an enabled project in the monorepo, we
get a link error because we try to link against non-existent cxxabi_shared.
More generally, we shouldn't change the behavior of the build based on
implicit things like whether a file happens to be at a specific path or
not.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63883
llvm-svn: 365222
|
|
|
|
|
|
|
|
| |
Add some missing documentation for the `LIBCXX_INCLUDE_TESTS` option.
Patch by Jean Heyd Meneide!
llvm-svn: 365154
|
|
|
|
|
|
| |
https://reviews.llvm.org/D63051
llvm-svn: 365080
|
|
|
|
|
|
|
|
|
|
|
|
| |
types.
It seems some people like to write types that can explicitly convert
to anything, but cannot be used to explicitly construct anything.
This patch makes tuple tolerate such types, as is required
by the standard.
llvm-svn: 365074
|
|
|
|
| |
llvm-svn: 365068
|
|
|
|
| |
llvm-svn: 364885
|
|
|
|
|
|
| |
bit code. NFC
llvm-svn: 364884
|
|
|
|
|
|
| |
can be included multiple times by multiple headers, and we don't want 'duplicate definition' errors.
llvm-svn: 364879
|
|
|
|
|
|
| |
language versions and w/o any compiler support. 'Working', in this case, means that it returns false in those cases.
llvm-svn: 364873
|
|
|
|
| |
llvm-svn: 364863
|
|
|
|
|
|
| |
https://reviews.llvm.org/D51262
llvm-svn: 364862
|
|
|
|
| |
llvm-svn: 364842
|
|
|
|
|
|
| |
as https://reviews.llvm.org/D58332, and then updated because I rewrote a couple of those routines to eliminate some UB. Thanks to Zoe for tghe patch.
llvm-svn: 364840
|
|
|
|
|
|
| |
https://reviews.llvm.org/D63053
llvm-svn: 364802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a clang-tidy warning when building something that uses
this file.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43226
llvm-svn: 364799
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mclow.lists
Subscribers: christof, ldionne, cfe-commits, libcxx-commits
Differential Revision: https://reviews.llvm.org/D62782
llvm-svn: 364798
|
|
|
|
|
|
| |
[[nodiscard]].
llvm-svn: 364732
|
|
|
|
|
|
| |
assignment operator. Fixes PR38638. Thanks to Jonathan Wakely for the report
llvm-svn: 364574
|
|
|
|
|
|
| |
for C++11 vs c++2a, so I tweaked the 'expected-error' bits that I added to match either of them.
llvm-svn: 364554
|
|
|
|
|
|
| |
char_traits. Seen on SO: test/std/strings/string.view/string.view.hash/char_type.hash.fail.cpp
llvm-svn: 364545
|
|
|
|
|
|
|
|
|
| |
There are some suspicious bot failures that I want to ensure aren't
caused by this patch.
I'll recommit tomorrow.
llvm-svn: 364363
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when _LIBCPP_ABI_UNSTABLE is defined.
User defined _LIBCPP_ABI_NAMESPACE will still be respected,
but the default version namespace in unstable mode will be the libc++ version
(Currently '__9000').
Previously `_LIBCPP_ABI_VERSION` and `_LIBCPP_ABI_NAMESPACE` were
`1` and `__1` respectively, whuch conflicted with the stable ABI
llvm-svn: 364354
|
|
|
|
| |
llvm-svn: 364241
|
|
|
|
| |
llvm-svn: 364239
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use binary mode to read test files in libcxx LibcxxTestFormat class.
This ensures that tests are read correctly independently of encoding,
and therefore fixes UnicodeDecodeError when file is opened in Python 3
that defaults to pure ASCII encoding.
Technically this could be also fixed via conditionally appending
encoding argument when opening the file in Python 3. However, since
the code in question only searches for fixed ASCII substrings reading
it in binary mode is simpler and more universal.
Differential Revision: https://reviews.llvm.org/D63346
llvm-svn: 364170
|
|
|
|
| |
llvm-svn: 364161
|
|
|
|
|
|
| |
The new meta-programming primitives are lower cost than the old versions. This patch removes those old versions and switches libc++ to use the new ones.
llvm-svn: 364160
|
|
|
|
| |
llvm-svn: 364149
|
|
|
|
|
|
|
|
|
| |
Clang provides __is_same that doesn't produce any instantiations
and just returns a bool. It's a lot faster than using std::is_same
I'll follow up with a patch to actually start using it.
llvm-svn: 364148
|
|
|
|
|
|
|
|
|
|
|
| |
The CMake CheckLibcxxAtomic module was always failing to compile
the example, even when libatomic wasn't needed. This was caused
because the check doesn't link a C++ runtime library to provide
std::terminate, which is required for exception support.
The check is still really broken, but <atomic> is better!
llvm-svn: 364146
|
|
|
|
| |
llvm-svn: 364144
|
|
|
|
| |
llvm-svn: 364142
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using class templates instead of alias templates causes a lot of
instantiations. As part of the move away from C++03, we want to
improve the efficiency of our meta-programming.
This patch lays the groundwork by introducing new _If, _EnableIf,
_And, _Or, and _IsValidExpansion (detect member). Future patches
will replace the existing implementations after verifying there
compile time differences.
llvm-svn: 364114
|
|
|
|
|
|
| |
https://reviews.llvm.org/D63574
llvm-svn: 364094
|
|
|
|
| |
llvm-svn: 364065
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These functions are key to allowing the use of rvalues and variadics
in C++03 mode. Everything works the same as in C++11, except for one
tangentially related case:
struct T {
T(T &&) = default;
};
In C++11, T has a deleted copy constructor. But in C++03 Clang gives
it both a move and a copy constructor. This seems reasonable enough
given the extensions it's using.
The other changes in this patch were the minimal set required
to keep the tests passing after the move/forward change. Most notably
the removal of the `__rv<unique_ptr>` hack that was present
in an attempt to make unique_ptr move only without language support.
llvm-svn: 364063
|
|
|
|
| |
llvm-svn: 364058
|
|
|
|
| |
llvm-svn: 364057
|
|
|
|
|
|
| |
We can use variadics with clang
llvm-svn: 364054
|
|
|
|
|
|
| |
The next step is to get move and forward working in C++03.
llvm-svn: 364053
|
|
|
|
| |
llvm-svn: 364050
|
|
|
|
|
|
|
|
|
|
| |
All the compilers we support provide these builtins. We don't
need to do a configuration dance anymore.
This patch also cleans up some dead or almost dead
C++11 feature detection macros.
llvm-svn: 364047
|
|
|
|
| |
llvm-svn: 364031
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The type timespec is unconditionally used in __threading_support.
Since the C library is only required to provide it in C11, this might
cause problems for platforms with external thread porting layer (i.e.
when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined) with pre-C11
C libraries.
In our downstream port of libc++ we used to provide a definition of
timespec in __external_threading, but this solution is not ideal
because timespec is not a reserved name.
This patch renames timespec into __libcpp_timespec_t in the
thread-related parts of libc++. For all cases except external
threading this type is an alias for ::timespec (and no functional
changes are intended).
In case of external threading it is expected that the
__external_threading header will either provide a similar typedef (if
timespec is available in the vendor's C library) or provide a
definition of __libcpp_timespec_t compatible with POSIX timespec.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne
Subscribers: dexonsmith, libcxx-commits, christof, carwil
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63328
llvm-svn: 364012
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-apply the change which was reverted in r363764 as-is after
breakages being resolved. Thanks Eric Fiselier for working
hard on this.
See also: https://bugs.llvm.org/show_bug.cgi?id=42330
Differential Revision: https://reviews.llvm.org/D44865
llvm-svn: 363993
|
|
|
|
|
|
|
|
|
|
|
| |
This is a re-application of r362986 (which was reverted in r363688) with fixes
for the issue that caused it to be reverted.
Thanks to Arthur O'Dwyer for the patch.
Differential Revision: https://reviews.llvm.org/D58587
llvm-svn: 363968
|