------------------------------------------------------------------------
r369537 | davidspickett | 2019-08-21 17:38:24 +0200 (Wed, 21 Aug 2019) | 7 lines
[libcxx] Only declare contents of threading API when
_LIBCPP_HAS_THREAD_API_EXTERNAL is not defined.
When it is defined they will be declared by the
__external_threading header instead.
Differential revision: https://reviews.llvm.org/D66518
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_90@369639 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r368867 | marshall | 2019-08-14 18:21:27 +0200 (Wed, 14 Aug 2019) | 1 line
Rework recursive_timed_mutex so that it uses __thread_id instead of using the lower-level __libcpp_thread_id. This is prep for fixing PR42918. Reviewed as https://reviews.llvm.org/D65895
------------------------------------------------------------------------
------------------------------------------------------------------------
r368916 | marshall | 2019-08-14 22:54:56 +0200 (Wed, 14 Aug 2019) | 1 line
Fix thread comparison by making sure we never pass our special 'not a thread' value to the underlying implementation. Fixes PR#42918.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_90@369369 91177308-0d34-0410-b5e6-96231b3b80d8
In r361572, we introduced library support for C++20 destroying delete
and decided to only define the library feature-test macro when the
compiler supports the underlying language feature. This patch reworks
the tests to mirror that.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@366263 91177308-0d34-0410-b5e6-96231b3b80d8
The tests for unordered_set and unordered_multiset were missing UNSUPPORTED
markup for Apple Clang 9.1, which is still being used on some CI bots.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@366259 91177308-0d34-0410-b5e6-96231b3b80d8
In particular, improve the compile time of the overload set builder
that variant uses to determine which alternative to construct.
Instead of having the __overload type construct itself recursively,
this patch uses a flat construction for the overload set.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@366033 91177308-0d34-0410-b5e6-96231b3b80d8
The test was brittle since it only went boom for one specific type, when
really it should go boom for all of them.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@366025 91177308-0d34-0410-b5e6-96231b3b80d8
The standard disallows narrowing conversions when constructing a variant.
This is checked by attempting to perform braced initialization of the
destination type from the argument type. However, braced initialization
can force the compiler (mostly clang) to eagerly instantiate the
constructors of the destintation type -- which can lead to errors in
a non-immediate context.
However, as variant is currently specified, the narrowing checks only
observably apply when the destination type is arithmetic. Meaning we can
skip the check for class types. Hense avoiding the hard errors.
In order to cause fewer build breakages, this patch avoids the narrowing
check except when the destination type is arithmetic.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@366022 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we implemented all one trillion tuple-like constructors using
a single generic overload. This worked fairly well, except that it
differed in behavior from the standard version because it didn't
consider both T&& and T const&. This was observable for certain
types.
This patch addresses that issue by splitting the generic constructor
in two. We now provide both T&& and T const& versions of the
tuple-like constructors (sort of).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@365973 91177308-0d34-0410-b5e6-96231b3b80d8
The paper P0608R3 - "A sane variant converting constructor" disallows
narrowing conversions in variant. It was meant to address this
surprising problem:
std::variant<std::string, bool> v = "abc";
assert(v.index() == 1); // constructs a bool.
However, it also disables every potentially narrowing conversion. For
example:
variant<unsigned> v = 0; // ill-formed
variant<string, double> v2 = 42; // ill-formed (int -> double narrows)
These latter changes break code. A lot of code. Within Google it broke
on the order of a hundred thousand target with thousands of root causes
responsible for the breakages.
Of the breakages related to the narrowing restrictions, none of them
exposed outstanding bugs. However, the breakages caused by boolean
conversions (~13 root causes), all but one of them were bugs.
For this reasons, I am adding a flag to disable the narrowing conversion
changes but not the boolean conversions one.
One purpose of this flag is to allow users to opt-out of breaking changes
in variant until the offending code can be cleaned up. For non-trivial
variant usages the amount of cleanup may be significant.
This flag is also required to support automated tooling, such as
clang-tidy, that can automatically fix code broken by this change.
In order for clang-tidy to know the correct alternative to construct,
it must know what alternative was being constructed previously, which
means running it over the old version of std::variant.
Because this change breaks so much code, I will be implementing the
aforementioned clang-tidy check in the very near future.
Additionally I'm plan present this new information to the committee so they can
re-consider if this is a breaking change we want to make.
I think libc++ should very seriously consider pulling this change
before the 9.0 release branch is cut. But that's a separate discussion
that I will start on the lists.
For now this is the minimal first step.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@365960 91177308-0d34-0410-b5e6-96231b3b80d8
The buildbots were changed to pass -DLIBCXX_CXX_ABI=libcxxabi, but
they don't provide an include path for the library, so cxxabi.h is
never found while building libc++.
This is a temporary change until the buildbots are updated or until
D63883 lands in a form that unbreaks the bots
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@365847 91177308-0d34-0410-b5e6-96231b3b80d8
When assigning an initializer list into set/map, libc++ would
leak memory if the initializer list contained equivalent keys
because we failed to check if the insertion was successful.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@365840 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than building up a list to iterate over later, just create multiple
install commands based on the configuration. This makes it easier to see what
is getting installed and allows for the install handling to be centralised. NFC
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@365562 91177308-0d34-0410-b5e6-96231b3b80d8
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.
This is a re-application of r365222 that had been reverted in r365233
because it broke the build bots. However, the build bots now specify
explicitly what ABI library they want to use (libc++abi), so this
commit should now be OK to merge.
Differential Revision: https://reviews.llvm.org/D63883
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@365326 91177308-0d34-0410-b5e6-96231b3b80d8
The implementations of __libcpp_mutex_destroy and __libcpp_condvar_destroy
are already NOPs, so this optimization is safe to perform.
See r365273 and PR27658 for more information.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@365281 91177308-0d34-0410-b5e6-96231b3b80d8
Jeffrey Smith II