aboutsummaryrefslogtreecommitdiff
path: root/libcxx
AgeCommit message (Collapse)AuthorFilesLines
2019-10-09Bump version to 9.0.1Tom Stellard1-1/+1
llvm-svn: 374218
2019-08-30Update libc++ release notesZoe Carver1-0/+33
This patch updates the libc++ release notes. I have picked out several features/fixes/updates that I think are worth mentioning. llvm-svn: 370514
2019-08-29ReleaseNotes: remove in-progress warning and empty sectionsHans Wennborg1-19/+3
llvm-svn: 370366
2019-08-26Merging r369364:Hans Wennborg1-1/+1
------------------------------------------------------------------------ r369364 | miyuki | 2019-08-20 12:19:55 +0200 (Tue, 20 Aug 2019) | 6 lines [libcxx] Fix build breakage on mips Fixes https://bugs.llvm.org/show_bug.cgi?id=43011 caused by https://reviews.llvm.org/D63284. Committing as obvious. ------------------------------------------------------------------------ llvm-svn: 369898
2019-08-22Merging r369537:Hans Wennborg1-2/+5
------------------------------------------------------------------------ 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 ------------------------------------------------------------------------ llvm-svn: 369639
2019-08-21Merging r369399:Hans Wennborg1-8/+11
------------------------------------------------------------------------ r369399 | marshall | 2019-08-20 18:16:23 +0200 (Tue, 20 Aug 2019) | 1 line Fix availability of __thread_id on builds with external threading. Reviewed as https://reviews.llvm.org/D66480 ------------------------------------------------------------------------ llvm-svn: 369498
2019-08-20Merging r368867 and r368916:Hans Wennborg4-78/+95
------------------------------------------------------------------------ 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. ------------------------------------------------------------------------ llvm-svn: 369369
2019-08-05Merging r366868:Hans Wennborg2-0/+21
------------------------------------------------------------------------ r366868 | rogfer01 | 2019-07-24 07:33:46 +0200 (Wed, 24 Jul 2019) | 6 lines [RISCV] Implement benchmark::cycleclock::Now This is a cherrypick of D64237 onto llvm/utils/benchmark and libcxx/utils/google-benchmark. Differential Revision: https://reviews.llvm.org/D65142 ------------------------------------------------------------------------ llvm-svn: 367813
2019-07-19Drop svn version suffix.Hans Wennborg1-1/+1
llvm-svn: 366547
2019-07-17[libc++] XFAIL a test that does not behave properly on older ClangLouis Dionne1-0/+4
rdar://53015486 llvm-svn: 366359
2019-07-16[libcxx] Rejigger test for destroying delete feature-test macrosLouis Dionne1-4/+13
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. llvm-svn: 366263
2019-07-16[libc++] Add missing UNSUPPORTED for CTAD testsLouis Dionne2-0/+2
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. llvm-svn: 366259
2019-07-16Add contains method to associative containers. This patch implements ↵Zoe Carver9-6/+263
P0458R2, adding contains to map, multimap, unordered_map, unordered_multimap, set, multiset, unordered_set, and unordered_multiset. llvm-svn: 366170
2019-07-15[libc++] Implement P0433: deduction guides for <unordered_map>Louis Dionne8-7/+1106
Thanks to Arthur O'Dwyer for the patch. Differential Revision: https://reviews.llvm.org/D58590 llvm-svn: 366124
2019-07-15Constrain workaround to avoid affecting other buildbotsEric Fiselier1-2/+4
llvm-svn: 366122
2019-07-14Improve compile time of variant.Eric Fiselier2-31/+154
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. llvm-svn: 366033
2019-07-14Add test for variant construction with duplicate types.Eric Fiselier1-0/+12
llvm-svn: 366032
2019-07-14Cleanup whitespace in <variant>. NFC.Eric Fiselier1-11/+7
llvm-svn: 366026
2019-07-14Harden variant test added in r366022Eric Fiselier1-3/+3
The test was brittle since it only went boom for one specific type, when really it should go boom for all of them. llvm-svn: 366025
2019-07-14Avoid eager template instantiation caused by the variant narrowing checks.Eric Fiselier2-9/+41
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. llvm-svn: 366022
2019-07-12Fix non-conformance it `std::tuple`.Eric Fiselier2-20/+47
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). llvm-svn: 365973
2019-07-12Add option to disable variant narrowing conversion changes.Eric Fiselier8-93/+105
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. llvm-svn: 365960
2019-07-12[libc++] Add XFAILs for CTAD tests on older compilersLouis Dionne2-0/+2
llvm-svn: 365923
2019-07-12Mark destroying delete test as UNSUPPORTED with clang 7Eric Fiselier1-1/+1
llvm-svn: 365856
2019-07-12Tolerate import errors in "not.py" implementationEric Fiselier1-4/+12
llvm-svn: 365855
2019-07-12Reorganize the 'bit' header to make most of the facilities available for ↵Marshall Clow5-117/+263
internal use pre-C++20. NFC for external users llvm-svn: 365854
2019-07-12Add another buildbot username to the workaround listEric Fiselier1-1/+1
llvm-svn: 365848
2019-07-12Attempt to override broken buildbot config for libc++abi.Eric Fiselier1-0/+8
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 llvm-svn: 365847
2019-07-11Fix memory leak in set and map.Eric Fiselier3-128/+129
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. llvm-svn: 365840
2019-07-11[libc++] Implement deduction guides for <unordered_set>Louis Dionne5-6/+702
Thanks to Arthur O'Dwyer for the patch. Differential Revision: https://reviews.llvm.org/D58617 llvm-svn: 365788
2019-07-09build: use multiple `install` rather than building up a listSaleem Abdulrasool1-12/+20
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 llvm-svn: 365562
2019-07-08Revert "[libc++] Take 2: Do not cleverly link against libc++abi just because ↵Vitaly Buka2-1/+14
it happens to be there" r365326 still breaks bots: http://lab.llvm.org:8011/builders/netbsd-amd64/builds/20712/steps/ninja%20build%20local/logs/stdio http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/39477/steps/test%20tsan%20in%20debug%20compiler-rt%20build/logs/stdio And probably others This reverts commit 945b9ec0693390ef35fe8c6b774495312246b8b6. llvm-svn: 365359
2019-07-08[libc++] Take 2: Do not cleverly link against libc++abi just because it ↵Louis Dionne2-14/+1
happens to 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. 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 llvm-svn: 365326
2019-07-08Make forward_list::remove/remove_if/unique all return void before C++20; ↵Marshall Clow6-82/+152
undoes that bit of D58332. Thanks to Mikhail Maltsev for pointing this out llvm-svn: 365290
2019-07-07Make ~mutex and ~condition_variable trivial on Windows.Eric Fiselier5-19/+66
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. llvm-svn: 365281
2019-07-07Fix PR27658 - Make ~mutex trivial when possible.Eric Fiselier6-20/+73
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
2019-07-06Make list::remove/remove_if/unique all return void before C++20; undoes that ↵Marshall Clow5-33/+103
bit of D58332. Thanks to Mikhail Maltsev for pointing this out llvm-svn: 365261
2019-07-05This patch makes swap functions constexpr. Both swap overloads, swap_ranges ↵Zoe Carver6-4/+70
and iter_swap are updated (with tests). llvm-svn: 365238
2019-07-05Revert "[libc++] Do not cleverly link against libc++abi just because it ↵Louis Dionne2-1/+14
happens to be there" This reverts r365222, which broke the libc++ build bots. llvm-svn: 365233
2019-07-05[libc++] Do not cleverly link against libc++abi just because it happens to ↵Louis Dionne2-14/+1
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
2019-07-04docs: add documentation for `LIBCXX_INCLUDE_TESTS`Saleem Abdulrasool1-0/+6
Add some missing documentation for the `LIBCXX_INCLUDE_TESTS` option. Patch by Jean Heyd Meneide! llvm-svn: 365154
2019-07-03Add tests for regex_match ambiguity (aka LWG2273). NFC. Reviewed as ↵Marshall Clow3-2/+50
https://reviews.llvm.org/D63051 llvm-svn: 365080
2019-07-03Fix tuple's conditionally explicit constructors for very weird userEric Fiselier2-1/+24
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
2019-07-03[libc++] Update availability markup for Filesystem on Apple platformsLouis Dionne2-11/+11
llvm-svn: 365068
2019-07-02Update status of papers for upcoming WG21 meeting. NFCMarshall Clow1-3/+3
llvm-svn: 364885
2019-07-02Use new '__libcpp_is_constant_evaluated' call to remove an '#ifdef' from the ↵Marshall Clow1-6/+2
bit code. NFC llvm-svn: 364884
2019-07-02Mark the newly added '__libcpp_is_constant_evaluated' as 'inline', since it ↵Marshall Clow1-2/+4
can be included multiple times by multiple headers, and we don't want 'duplicate definition' errors. llvm-svn: 364879
2019-07-01Add a private call '__libcpp_is_constant_evaluated' which 'works' for old ↵Marshall Clow2-1/+40
language versions and w/o any compiler support. 'Working', in this case, means that it returns false in those cases. llvm-svn: 364873
2019-07-01Update status for bit operationsMarshall Clow1-2/+2
llvm-svn: 364863
2019-07-01Bit Operations: P0556, P0553 and P1355. Reviewed as: ↵Marshall Clow14-18/+2158
https://reviews.llvm.org/D51262 llvm-svn: 364862