summaryrefslogtreecommitdiffstats
path: root/libcxx/test/std
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Mark iostreams test as XFAIL on older macOSesLouis Dionne2019-09-231-0/+12
| | | | llvm-svn: 372620
* Revert "Revert "Implement std::condition_variable via ↵Dan Albert2019-09-181-11/+22
| | | | | | | | | | pthread_cond_clockwait() where available"" With the fix for non-Linux. This reverts commit c1c519d2f1a66dd2eeaa4c321d8d7b50f623eb71. llvm-svn: 372242
* Revert "Implement std::condition_variable via pthread_cond_clockwait() where ↵Dan Albert2019-09-161-22/+11
| | | | | | | | available" This reverts commit 5e37d7f9ff257ec62d733d3d94b11f03e0fe51ca. llvm-svn: 372034
* Implement std::condition_variable via pthread_cond_clockwait() where availableDan Albert2019-09-161-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | std::condition_variable is currently implemented via pthread_cond_timedwait() on systems that use pthread. This is problematic, since that function waits by default on CLOCK_REALTIME and libc++ does not provide any mechanism to change from this default. Due to this, regardless of if condition_variable::wait_until() is called with a chrono::system_clock or chrono::steady_clock parameter, condition_variable::wait_until() will wait using CLOCK_REALTIME. This is not accurate to the C++ standard as calling condition_variable::wait_until() with a chrono::steady_clock parameter should use CLOCK_MONOTONIC. This is particularly problematic because CLOCK_REALTIME is a bad choice as it is subject to discontinuous time adjustments, that may cause condition_variable::wait_until() to immediately timeout or wait indefinitely. This change fixes this issue with a new POSIX function, pthread_cond_clockwait() proposed on http://austingroupbugs.net/view.php?id=1216. The new function is similar to pthread_cond_timedwait() with the addition of a clock parameter that allows it to wait using either CLOCK_REALTIME or CLOCK_MONOTONIC, thus allowing condition_variable::wait_until() to wait using CLOCK_REALTIME for chrono::system_clock and CLOCK_MONOTONIC for chrono::steady_clock. pthread_cond_clockwait() is implemented in glibc (2.30 and later) and Android's bionic (Android API version 30 and later). This change additionally makes wait_for() and wait_until() with clocks other than chrono::system_clock use CLOCK_MONOTONIC.<Paste> llvm-svn: 372016
* Fix various test failures with GCCEric Fiselier2019-09-132-3/+7
| | | | llvm-svn: 371880
* Fix failing negative compilation test for some versions of ClangEric Fiselier2019-09-131-0/+1
| | | | llvm-svn: 371874
* Recommit r370502: Make `vector` unconditionally move elements whenEric Fiselier2019-09-132-45/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | exceptions are disabled. The patch was reverted due to some confusion about non-movable types. ie types that explicitly delete their move constructors. However, such types do not meet the requirement for `MoveConstructible`, which is required by `std::vector`: 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: 371867
* Only initialize the streams cout/wcout/cerr/wcerr etc once, rather than any ↵Marshall Clow2019-09-131-0/+32
| | | | | | time Init::Init is called. Fixes PR#43300 llvm-svn: 371864
* [libc++] Add a test for resizing of a vector with copy-only elementsLouis Dionne2019-09-051-0/+45
| | | | | | See https://reviews.llvm.org/D62228#1658620 llvm-svn: 371067
* [libc++] Add yet another test for inverted character classesLouis Dionne2019-08-271-0/+3
| | | | | | | | This was reported as part of a bug report that ended up being a duplicate for r340609, but I'm adding the test case since it's ever so slightly different from what we had before. llvm-svn: 370109
* [libc++] Fix broken <random> testLouis Dionne2019-08-221-16/+23
| | | | | | | | | | | | In r369429, I hoisted a floating point computation to a variable in order to remove a warning. However, it turns out this doesn't play well with floating point arithmetic. This commit reverts r369429 and instead casts the result of the floating point computation to remove the warning. Whether hoisting the computaiton to a variable should give the same result can be investigated independently. llvm-svn: 369693
* libcxx: Rename last two .hpp files in libcxx to .hNico Weber2019-08-2110-13/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D66544 llvm-svn: 369597
* libcxx: Rename .hpp files in libcxx/test/support to .hNico Weber2019-08-21401-641/+641
| | | | | | | | | | | | | | | | | | | | | | | | | | LLVM uses .h as its extension for header files. Files renamed using: for f in libcxx/test/support/*.hpp; do git mv $f ${f%.hpp}.h; done References to the files updated using: for f in $(git diff master | grep 'rename from' | cut -f 3 -d ' '); do a=$(basename $f); echo $a; rg -l $a libcxx | xargs sed -i '' "s/$a/${a%.hpp}.h/"; done HPP include guards updated manually using: for f in $(git diff master | grep 'rename from' | cut -f 3 -d ' '); do echo ${f%.hpp}.h ; done | xargs mvim Differential Revision: https://reviews.llvm.org/D66104 llvm-svn: 369481
* Fix a couple of unguarded operator, calls in algorithm. Fixes PR#43063. ↵Marshall Clow2019-08-2012-0/+93
| | | | | | Updated all the heap tests to check this. llvm-svn: 369448
* [libc++] Fix std::abs testsZoe Carver2019-08-201-7/+14
| | | | | | | | | | On systems where sizeof(long) == sizeof(int) the current tests failed. This commit updates those tests to work on all systems. std::abs has specific long specializations which can be used instead. llvm-svn: 369437
* [libc++] Avoid implicit conversion warning in a <random> testLouis Dionne2019-08-201-23/+16
| | | | | | | | | | By stashing the computation of `E::max() - E::min()` in a variable, we avoid the warning introduced in r367497. Note that we use `auto` to avoid having to deduce the type of the computation, which is not a problem since Clang provides `auto` as an extension even in C++03 (and we disable warnings related to using C++11 extensions in the test suite). llvm-svn: 369429
* [libc++] Implement LWG 3199Louis Dionne2019-08-201-0/+12
| | | | | | | | | | | | | | | | 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
* [libc++] Precise XFAIL for AppleClang 11Louis Dionne2019-08-201-1/+1
| | | | | | This test doesn't fail on all patch levels of AppleClang 11 llvm-svn: 369420
* [libc++] fix test for unsigned charZoe Carver2019-08-201-1/+7
| | | | | | | | | On some systems char is unsigned. If that is the case, we will now test signed char twice in std::abs. NFC. Fixes the build bots. llvm-svn: 369413
* [libc++] Disable <chrono> ""d and ""y literal tests on AppleClang 10.0.0Louis Dionne2019-08-202-0/+2
| | | | | | | | In r368882, I enabled those tests for all AppleClang's above version 9. However, it turns out that the feature is only supported starting with AppleClang 10.0.1, not AppleClang 10.0.0. This commit fixes that hole. llvm-svn: 369409
* [libc++] std::abs should not return doubleZoe Carver2019-08-202-0/+97
| | | | | | | | Implement LWG Issue 2735 by adding std::abs tests for several types and checking their return value. NFC. llvm-svn: 369394
* [libc++] Add XFAIL for is_base_of test on AppleClang 11Louis Dionne2019-08-191-2/+2
| | | | llvm-svn: 369280
* [libc++] Mark <chrono> test as unsupported on AppleClang 9Louis Dionne2019-08-141-0/+1
| | | | llvm-svn: 368914
* [libc++] Mark std::tuple CTAD test as failing on AppleClang 9Louis Dionne2019-08-141-0/+1
| | | | | | | | Like CTAD for std::unordered_set, AppleClang 9's support for CTAD is insufficient. I suspect the corresponding LLVM Clang is broken too, but we don't seem to have testers using that Clang. llvm-svn: 368911
* [libc++] Enable <chrono> ""d and ""y literals for AppleClang 10 and upLouis Dionne2019-08-142-2/+2
| | | | | | AppleClang supports those literals starting in version 10.0.1. llvm-svn: 368882
* [libc++] Mark two <chrono> tests as unsupported on AppleClang 11Louis Dionne2019-08-132-2/+2
| | | | | | | The operator""y and operator""d will eventually be supported by AppleClang, but no released version supports them at the moment. llvm-svn: 368749
* [libc++] Implement CTAD for std::tupleLouis Dionne2019-08-121-13/+57
| | | | | | | | | | | | | | | | | | | | | 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
* Implement hh_mm_ss from P1466R3. Reviewed as https://reviews.llvm.org/D65365.Marshall Clow2019-08-0815-0/+782
| | | | llvm-svn: 368299
* [libc++] Take 2: Integrate the PSTL into libc++Louis Dionne2019-08-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-041-41/+0
| | | | | | | | | 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-031-0/+41
| | | | | | | | | | | 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
* libcxx: Define __STDCPP_THREADS__ to 1, not to __cplusplus.Nico Weber2019-07-301-1/+3
| | | | | | | | | | | | | | | | | | | [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 tests with modules enabledEric Fiselier2019-07-294-0/+4
| | | | llvm-svn: 367268
* Fix a bug in std::chrono::abs where it would fail when the duration's period ↵Marshall Clow2019-07-261-0/+6
| | | | | | had not been reduced.s llvm-svn: 367120
* Implement change #4 of P1466: Change weekday to accept both 0 and 7 as ↵Marshall Clow2019-07-2519-60/+155
| | | | | | 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-231-1/+2
| | | | | | 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
* [libc++] Set __file_ to 0 in basic_filebuf::close() even if fclose failsPetr Hosek2019-07-221-0/+56
| | | | | | | | | | | | | | | | | | | | 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-191-1/+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++] Integrate the PSTL into libc++Louis Dionne2019-07-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | 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++] Add C++17 deduction guides for std::functionLouis Dionne2019-07-183-0/+283
| | | | | | | | | | | | Summary: http://llvm.org/PR39606 Reviewers: Quuxplusone Subscribers: christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D54410 llvm-svn: 366484
* [libcxx] Rejigger test for destroying delete feature-test macrosLouis Dionne2019-07-161-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
* [libc++] Add missing UNSUPPORTED for CTAD testsLouis Dionne2019-07-162-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
* Add contains method to associative containers. This patch implements ↵Zoe Carver2019-07-164-0/+212
| | | | | | 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-156-0/+965
| | | | | | | | Thanks to Arthur O'Dwyer for the patch. Differential Revision: https://reviews.llvm.org/D58590 llvm-svn: 366124
* Add test for variant construction with duplicate types.Eric Fiselier2019-07-141-0/+12
| | | | llvm-svn: 366032
* Harden variant test added in r366022Eric Fiselier2019-07-141-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
* Avoid eager template instantiation caused by the variant narrowing checks.Eric Fiselier2019-07-141-1/+13
| | | | | | | | | | | | | | | | | | 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-0/+16
| | | | | | | | | | | | | | 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-126-93/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [libc++] Add XFAILs for CTAD tests on older compilersLouis Dionne2019-07-122-0/+2
| | | | llvm-svn: 365923
OpenPOWER on IntegriCloud