summaryrefslogtreecommitdiffstats
path: root/libcxx/include
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Mark usage of _Atomic with __extension__Louis Dionne2019-09-031-1/+1
| | | | | | | | | An upcoming change in Clang will flag _Atomic as being a C11 extension. To avoid generating this warning in libc++, this commit marks the only use of _Atomic with the __extension__ extension, which suppresses such warnings. llvm-svn: 370796
* Make `vector` unconditionally move elements when exceptions are disabled.Eric Fiselier2019-08-302-10/+25
| | | | | | | | | | | | | | | | | | | | | | | | Summary: `std::vector<T>` is free choose between using copy or move operations when it needs to resize. The standard only candidates that the correct exception safety guarantees are provided. When exceptions are disabled these guarantees are trivially satisfied. Meaning vector is free to optimize it's implementation by moving instead of copying. This patch makes `std::vector` unconditionally move elements when exceptions are disabled. This optimization is conforming according to the current standard wording. There are concerns that moving in `-fno-noexceptions`mode will be a surprise to users. For example, a user may be surprised to find their code is slower with exceptions enabled than it is disabled. I'm sympathetic to this surprised, but I don't think it should block this optimization. Reviewers: mclow.lists, ldionne, rsmith Reviewed By: ldionne Subscribers: zoecarver, christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D62228 llvm-svn: 370502
* [libc++] Fix visibility of __vector_base_common on GCCLouis Dionne2019-08-281-1/+1
| | | | | | | | | | | Since we build the library with -fvisibility=hidden, the shared object wouldn't contain __vector_base_common<true>::__throw_length_error() and __vector_base_common<true>::__throw_out_of_range(), leading to link errors. This only happened on GCC for some reason. https://llvm.org/PR43140 llvm-svn: 370240
* [libcxx] Only declare contents of threading API whenDavid Spickett2019-08-211-2/+5
| | | | | | | | | | | _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: 369537
* Add a missing _VSTD:: before a call to merge. Fixes PR43034. Checked the ↵Marshall Clow2019-08-201-1/+1
| | | | | | rest of 'algorithm' looking for unqualified calls. Didn't find any. llvm-svn: 369463
* Fix a couple of unguarded operator, calls in algorithm. Fixes PR#43063. ↵Marshall Clow2019-08-201-13/+13
| | | | | | Updated all the heap tests to check this. llvm-svn: 369448
* [libc++] Implement LWG 3199Louis Dionne2019-08-201-1/+1
| | | | | | | | | | | | | | | | Summary: The resolution of LWG 3199 makes sure that input-streaming into an empty bitset does not set the failbit on the input stream. Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65105 llvm-svn: 369422
* Fix availability of __thread_id on builds with external threading. Reviewed ↵Marshall Clow2019-08-201-8/+11
| | | | | | as https://reviews.llvm.org/D66480 llvm-svn: 369399
* [libc++] Explicitly cast in generate_canonicalLouis Dionne2019-08-201-1/+1
| | | | | | | | | | A new clang warning introduced in r367497 was complaining about the change in value. Thanks to Brian Cain for the patch. Differential Revision: https://reviews.llvm.org/D66422 llvm-svn: 369393
* [libcxx] Fix build breakage on mipsMikhail Maltsev2019-08-201-1/+1
| | | | | | | | | Fixes https://bugs.llvm.org/show_bug.cgi?id=43011 caused by https://reviews.llvm.org/D63284. Committing as obvious. llvm-svn: 369364
* [libc++] reverts commit a5f5aad568bb7a91ceee47641f3076ac339ef8c7.Zoe Carver2019-08-191-110/+260
| | | | | | | | | The commit being reverted caused segfaults when building with libc++ and GCC (and possibly other configurations). Differential Revision: https://reviews.llvm.org/D62868 llvm-svn: 369270
* Fix thread comparison by making sure we never pass our special 'not a ↵Marshall Clow2019-08-141-3/+11
| | | | | | thread' value to the underlying implementation. Fixes PR#42918. llvm-svn: 368916
* This commit removes std::shared_ptr::make_shared and ↵Zoe Carver2019-08-141-260/+110
| | | | | | std::shared_ptr::allocate_shared as they are not part of the standard. This commit also adds the helper function "__create_with_cntrl_block" which std::allocate_shared and std::make_shared have been updated to use. llvm-svn: 368885
* [libc++] Enable <chrono> ""d and ""y literals for AppleClang 10 and upLouis Dionne2019-08-141-3/+4
| | | | | | AppleClang supports those literals starting in version 10.0.1. llvm-svn: 368882
* [libc++] Do not define _LIBCPP_CLANG_VER for non-LLVM ClangLouis Dionne2019-08-141-6/+2
| | | | | | | | | | | | | In r292833, we started defining _LIBCPP_CLANG_VER to 0 for Apple Clang. The result is that AppleClang is detected as being a very old version of LLVM Clang (version 0), which is obviously incorrect. I believe this was added so that we don't have to check whether _LIBCPP_CLANG_VER is defined prior to comparing it with a number (which can trigger a warning). This commit also fixes the two places that use the macro correspondingly. llvm-svn: 368880
* Rework recursive_timed_mutex so that it uses __thread_id instead of using ↵Marshall Clow2019-08-143-72/+81
| | | | | | the lower-level __libcpp_thread_id. This is prep for fixing PR42918. Reviewed as https://reviews.llvm.org/D65895 llvm-svn: 368867
* [libc++] Always build with -fvisibility=hiddenLouis Dionne2019-08-132-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This avoids symbols being accidentally exported from the dylib when they shouldn't. The next step is to use a pragma to apply hidden visibility to all declarations (unless otherwise specified), which will allow us to drop the per-declaration hidden visibility attributes we currently have. This also has the nice side effect of making sure the dylib exports the same symbols regardless of the optimization level. PR38138 Reviewers: EricWF, mclow.lists Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D62868 llvm-svn: 368703
* [libc++] Use [[nodiscard]] for lock_guard, as an extensionLouis Dionne2019-08-131-2/+3
| | | | | | | | | | | | | | | | | | | Summary: D64914 added support for applying [[nodiscard]] to constructors. This commit uses that capability to flag incorrect uses of std::lock_guard where one forgets to actually create a variable for the lock_guard. rdar://45790820 Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits, Quuxplusone, lebedev.ri Tags: #libc Differential Revision: https://reviews.llvm.org/D65900 llvm-svn: 368664
* [libc++] Implement CTAD for std::tupleLouis Dionne2019-08-121-7/+21
| | | | | | | | | | | | | | | | | | | | | Summary: We were using implicit deduction guides instead of explicit ones, however the implicit ones don't do work anymore when changing the constructors. This commit adds the actual guides specified in the Standard to make libc++ (1) closer to the Standard and (2) more resistent to changes in std::tuple's constructors. Reviewers: Quuxplusone Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65225 llvm-svn: 368599
* Improve codegen for deque.Eric Fiselier2019-08-122-25/+117
| | | | | | | | | | | | | | | | | | | | | | | This patch rewrites a few loops in deque and split_buffer to better optimize the codegen. For constructors like `deque<unsigned char> d(500000, 0);` this patch results in a 2x speedup. The patch improves the codegen in roughly three ways: 1. Changes do { ... } while (...) loops into more typical for loops. The optimizer can reason about normal looking loops better. 2. Split the iteration over a range into (A) iteration over the blocks, then (B) iteration within the block. This nested structure helps LLVM lower the inner loop to `memset`. 3. Do fewer things each iteration. Some of these loops were incrementing or changing 4-5 variables every loop (in addition to the construction). Previously most loops would increment the end pointer, the size, and decrement the count of remaining items to construct. Now we only increment a single pointer for most iterations. llvm-svn: 368547
* Implement hh_mm_ss from P1466R3. Reviewed as https://reviews.llvm.org/D65365.Marshall Clow2019-08-081-6/+114
| | | | llvm-svn: 368299
* [pstl][libc++] Provide uglified header names for interface headersLouis Dionne2019-08-064-4/+4
| | | | | | | | | | | For the few (currently four) headers that make up the PSTL's interface to other Standard Libraries, provide a stable uglified header file that can be included by those Standard Libraries. We can then more easily change the internal organization of the PSTL without having to change the integration with Standard Libraries. llvm-svn: 368088
* [libc++] Take 2: Integrate the PSTL into libc++Louis Dionne2019-08-057-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when configuring libc++ in CMake. When that option is enabled, libc++ will assume that the PSTL can be found somewhere on the CMake module path, and it will provide the C++17 parallel algorithms based on the PSTL (that is assumed to be available). The commit also adds support for running the PSTL tests as part of the libc++ test suite. The first attempt to commit this failed because it exposed a bug in the tests for modules. Now that this has been fixed, it should be safe to commit this. Reviewers: EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF Tags: #libc Differential Revision: https://reviews.llvm.org/D60480 llvm-svn: 367903
* Revert "Suppress -Wctad-maybe-unsupported on types w/o deduction guides."Eric Fiselier2019-08-047-18/+1
| | | | | | | | | Some modules builds are issuing buggy diagnostics. The cause of which is TBD. This reverts commit r@367770. llvm-svn: 367777
* Suppress -Wctad-maybe-unsupported on types w/o deduction guides.Eric Fiselier2019-08-037-1/+18
| | | | | | | | | | | There are a handful of standard library types that are intended to support CTAD but don't need any explicit deduction guides to do so. This patch adds a dummy deduction guide to those types to suppress -Wctad-maybe-unsupported (which gets emitted in user code). llvm-svn: 367770
* Revert accidental change to __member_pointer_traits_imp.Eric Fiselier2019-08-031-1/+3
| | | | | | | A previous patch accidentally made the primary template an incomplete type. This broke some C++03 constructs. llvm-svn: 367762
* Simplify <type_traits> implementations.Eric Fiselier2019-08-031-67/+36
| | | | | | | | | | | | This patch rewrites a number of old meta-function implementations that assumed const/volatile could not be safely applied to all types. This is no longer the case, though for some types (Ex function types), the const qualifier can be ignored. The largest improvement in this patch is the reduction of is_function. Thanks to Matt Calabrese for the improved implementation. llvm-svn: 367749
* Refactor deque to centralize handling of spare blocks.Eric Fiselier2019-08-011-48/+50
| | | | | | | | I have upcoming changes that modify how deque handles spare blocks. This cleanup is intended to make those changes easier to review and understand. This patch should have NFC. llvm-svn: 367631
* Change default bucket count in hash_set/hash_map.Eric Fiselier2019-08-012-13/+12
| | | | | | | | | | | Previously these types rehashed to a table of 193 elements upon construction. But this is non-ideal, first because default constructors should not allocate unless necessary, and second because 193 is big and can waste a bunch of memory. This number had previously been chosen to match GCC's implementation. llvm-svn: 367605
* libcxx: Define __STDCPP_THREADS__ to 1, not to __cplusplus.Nico Weber2019-07-302-4/+8
| | | | | | | | | | | | | | | | | | | [cpp.predefined]p2: __STDCPP_THREADS__ Defined, and has the value integer literal 1, if and only if a program can have more than one thread of execution . Also define it only if it's not defined already, since it's supposed to be defined by the compiler. Also move it from thread to __config (which requires setting it only if _LIBCPP_HAS_NO_THREADS is not defined). Part of PR33230. The intent is to eventually make the compiler define this instead. llvm-svn: 367316
* Fix PR35637: suboptimal codegen for `vector<unsigned char>`.Eric Fiselier2019-07-281-95/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The optimizer is petulant and temperamental. In this case LLVM failed to lower the the "insert at end" loop used by`vector<unsigned char>` to a `memset` despite `memset` being substantially faster over a range of bytes. LLVM has the ability to lower loops to `memset` whet appropriate, but the odd nature of libc++'s loops prevented the optimization from taking places. This patch addresses the issue by rewriting the loops from the form `do [ ... --__n; } while (__n > 0);` to instead use a for loop over a pointer range (For example: `for (auto *__i = ...; __i < __e; ++__i)`). This patch also rewrites the asan annotations to unposion all additional memory at the start of the loop instead of once per iterations. This could potentially permit false negatives where the constructor of element N attempts to access element N + 1 during its construction. The before and after results for the `BM_ConstructSize/vector_byte/5140480_mean` benchmark (run 5 times) are: -------------------------------------------------------------------------------------------- Benchmark Time CPU Iterations -------------------------------------------------------------------------------------------- Before ------ BM_ConstructSize/vector_byte/5140480_mean 12530140 ns 12469693 ns N/A BM_ConstructSize/vector_byte/5140480_median 12512818 ns 12445571 ns N/A BM_ConstructSize/vector_byte/5140480_stddev 106224 ns 107907 ns 5 ----- After ----- BM_ConstructSize/vector_byte/5140480_mean 167285 ns 166500 ns N/A BM_ConstructSize/vector_byte/5140480_median 166749 ns 166069 ns N/A BM_ConstructSize/vector_byte/5140480_stddev 3242 ns 3184 ns 5 llvm-svn: 367183
* Fix a bug in std::chrono::abs where it would fail when the duration's period ↵Marshall Clow2019-07-261-1/+1
| | | | | | had not been reduced.s llvm-svn: 367120
* [NFC][libcxx] Add comments about making mutex/condition_variable trivial on ↵Louis Dionne2019-07-251-3/+13
| | | | | | | | | Apple platforms Leaving some comments behind so that we avoid re-having that discussion in the future. llvm-svn: 367048
* Implement change #4 of P1466: Change weekday to accept both 0 and 7 as ↵Marshall Clow2019-07-251-6/+7
| | | | | | Sunday. Add accessors 'c_encoding' and 'iso_encoding' to provide different interpretations of the weekday. Remove 'operator unsigned' llvm-svn: 366981
* Implement most of P1612R1: Relocate endian. Moves the std::endian ↵Marshall Clow2019-07-232-15/+21
| | | | | | functionality from 'type-traits' to 'bit'. No other change. The reason that this is 'partial' is that P1621 also recommends a feature-test macro, but I don't have the value for that one yet. In a month or so, I'll add that llvm-svn: 366776
* [NFC][libc++] Add missing EXPLICIT to pair and tuple synopsisLouis Dionne2019-07-222-16/+16
| | | | | | | The constructors for std::pair and std::tuple have been made conditionally explicit, however the synopsis in the headers do not reflect that. llvm-svn: 366735
* [libc++] Set __file_ to 0 in basic_filebuf::close() even if fclose failsPetr Hosek2019-07-221-3/+2
| | | | | | | | | | | | | | | | | | | | This issue was detected by ASan in one of our tests. This test manually invokes basic_filebuf::cloe(). fclose(__h.release() returned a non-zero exit status, so __file_ wasn't set to 0. Later when basic_filebuf destructor ran, we would enter the if (__file_) block again leading to heap-use-after-free error. The POSIX specification for fclose says that independently of the return value, fclose closes the underlying file descriptor and any further access (including another call to fclose()) to the stream results in undefined behavior. This is exactly what happened in our test case. To avoid this issue, we have to always set __file_ to 0 independently of the fclose return value. Differential Revision: https://reviews.llvm.org/D64979 llvm-svn: 366730
* Revert "[libc++] Integrate the PSTL into libc++"Louis Dionne2019-07-197-37/+0
| | | | | | | This reverts r366593, which caused unforeseen breakage on the build bots. I'm reverting until the problems have been figured out and fixed. llvm-svn: 366603
* [libc++] Use _EnableIf instead of std::enable_if in deduction guides for map ↵Louis Dionne2019-07-192-24/+24
| | | | | | and set llvm-svn: 366594
* [libc++] Integrate the PSTL into libc++Louis Dionne2019-07-197-0/+37
| | | | | | | | | | | | | | | | | | | | | | Summary: This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when configuring libc++ in CMake. When that option is enabled, libc++ will assume that the PSTL can be found somewhere on the CMake module path, and it will provide the C++17 parallel algorithms based on the PSTL (that is assumed to be available). The commit also adds support for running the PSTL tests as part of the libc++ test suite. Reviewers: rodgert, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF Tags: #libc Differential Revision: https://reviews.llvm.org/D60480 llvm-svn: 366593
* [libc++] Fix link error with _LIBCPP_HIDE_FROM_ABI_PER_TU and std::stringLouis Dionne2019-07-191-10/+0
| | | | | | | | | | | | | | | | | | | | | Summary: This is effectively a revert of r344616, which was a partial fix for PR38964 (compilation of <string> with GCC in C++03 mode). However, that configuration is explicitly not supported anymore and that partial fix breaks compilation with Clang when per-TU insulation is provided. PR42676 rdar://52899715 Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D64941 llvm-svn: 366567
* [libc++] Add C++17 deduction guides for std::functionLouis Dionne2019-07-181-0/+54
| | | | | | | | | | | | Summary: http://llvm.org/PR39606 Reviewers: Quuxplusone Subscribers: christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D54410 llvm-svn: 366484
* Bump the trunk version to 10.0.0svnHans Wennborg2019-07-182-2/+2
| | | | | | and clear the release notes. llvm-svn: 366427
* Add contains method to associative containers. This patch implements ↵Zoe Carver2019-07-164-5/+50
| | | | | | P0458R2, adding contains to map, multimap, unordered_map, unordered_multimap, set, multiset, unordered_set, and unordered_multiset. llvm-svn: 366170
* [libc++] Implement P0433: deduction guides for <unordered_map>Louis Dionne2019-07-151-6/+140
| | | | | | | | Thanks to Arthur O'Dwyer for the patch. Differential Revision: https://reviews.llvm.org/D58590 llvm-svn: 366124
* Improve compile time of variant.Eric Fiselier2019-07-141-31/+36
| | | | | | | | | | 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
* Cleanup whitespace in <variant>. NFC.Eric Fiselier2019-07-141-11/+7
| | | | llvm-svn: 366026
* Avoid eager template instantiation caused by the variant narrowing checks.Eric Fiselier2019-07-141-8/+28
| | | | | | | | | | | | | | | | | | 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
* Fix non-conformance it `std::tuple`.Eric Fiselier2019-07-121-20/+31
| | | | | | | | | | | | | | 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
* Add option to disable variant narrowing conversion changes.Eric Fiselier2019-07-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud