summaryrefslogtreecommitdiffstats
path: root/libcxx
Commit message (Collapse)AuthorAgeFilesLines
* force the bots to cycleEric Fiselier2019-05-091-1/+0
| | | | llvm-svn: 360306
* Mark private function __sign as constexpr.Marshall Clow2019-05-071-1/+1
| | | | llvm-svn: 360167
* Remove unneeded <algorithm> include in cmath.Eric Fiselier2019-05-061-1/+0
| | | | | | | It's a remnant from an earlier version of the lerp change and is unneeded. llvm-svn: 360098
* [libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining themPetr Hosek2019-05-061-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | When builing the hermetic static library, the compiler switch -fvisibility-global-new-delete-hidden is necessary to get the new and delete operator definitions made correctly. However, when those definitions are not included in the library, then this switch does harm. With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF symbols makes it an error to leave them undefined or defined via dynamic linking that should generate PLTs for -shared linking (lld makes this a hard error even without -z defs). Though leaving the symbols undefined would usually work in practice if the linker were to allow it (and the user didn't pass -z defs), this actually indicates a real problem that could bite some target configurations more subtly at runtime. For example, x86-32 ELF -fpic code generation uses hidden visibility on declarations in the caller's scope as a signal that the call will never be resolved to a PLT entry and so doesn't have to meet the special ABI requirements for PLT calls (setting %ebx). Since these functions might actually be resolved to PLT entries at link time (we don't know what the user is linking in when the hermetic library doesn't provide all the symbols itself), it's not safe for the compiler to treat their declarations at call sites as having hidden visibility. Differential Revision: https://reviews.llvm.org/D61571 llvm-svn: 360003
* Mark is_trivially_destructible as unsupported with apple-clang-9Nico Weber2019-05-031-0/+1
| | | | | | See discussion on https://reviews.llvm.org/D48292 llvm-svn: 359907
* [libc++][test] Remove non-portable assumption that thread's constructor ↵Casey Carter2019-05-021-10/+19
| | | | | | | | | | | | | allocates with ::new Drive-by: * Fix potential race between check and update of `throw_one` in `operator new` * Fix latent bug in `operator delete`, which shouldn't decrement `outstanding_new` when passed a null pointer * Specifically catch the expected `bad_alloc` in `main` instead of `...` Differential Revision: https://reviews.llvm.org/D50860 llvm-svn: 359827
* [libc++][CMake] Link against libSystem on Apple platformsLouis Dionne2019-05-022-0/+11
| | | | | | | | Instead of manually linking against libm/librt/libpthread, we should be linking against libSystem on Apple platforms, and only that. libm and libpthread are symlinks to libSystem anyway. llvm-svn: 359808
* [gn] Support for building libc++Petr Hosek2019-05-021-2/+1
| | | | | | | | | | | | This change introduces support for building libc++. The library build should be complete, but not all CMake options have been replicated in GN. We also don't support tests yet. We only support two stage build at the moment. Differential Revision: https://reviews.llvm.org/D61143 llvm-svn: 359806
* [libcxx] cmake - guard list removeBrian Cain2019-05-021-4/+6
| | | | | | | REMOVE_ITEM fails if CMAKE_REQUIRED_LIBRARIES is empty on some versions of cmake. llvm-svn: 359755
* Add missing locale requirement to test.Dan Albert2019-05-011-0/+1
| | | | | | | | Linux is failing even though the test runner does report this locale is available, but the test still isn't expected to work on platforms without the locale (like Android). llvm-svn: 359726
* [WebAssembly] WASI support for libcxxDan Gohman2019-05-015-6/+12
| | | | | | | | | | | | | This adds explicit support for the WASI platform to libcxx. WASI libc uses some components from musl, however it's not fully compatible with musl, so we're planning to stop using _LIBCPP_HAS_MUSL_LIBC and customize for WASI libc specifically. Differential Revision: https://reviews.llvm.org/D61336 Reviewers: sbc100, ldionne llvm-svn: 359703
* Get rid of a bunch of 'unused variable' warnings in test when run with ↵Marshall Clow2019-05-015-4/+8
| | | | | | debug_level set. NFC llvm-svn: 359672
* [libcxx] Move CMake file to src, avoid using globsPetr Hosek2019-05-012-17/+78
| | | | | | | | | This addresses the longstanding FIXME and makes libc++ build more similar to other runtimes. Differential Revision: https://reviews.llvm.org/D61275 llvm-svn: 359656
* Fix a bunch of unordered container tests that were failing when ↵Marshall Clow2019-05-0118-46/+41
| | | | | | _LIBCPP_DEBUG was set. llvm-svn: 359642
* Support overaligned types in `aligned_storage`.Eric Fiselier2019-04-302-2/+12
| | | | | | | | | | | | | | | | | Summary: The current implementation of aligned storage was written before we had `alignas`, so it used a list of builtin types to force the alignment. But this doesn't work overaligned requests. This patch adds a fallback case supporting over-alignment. It only affects case that were previously ill-formed. Reviewers: rsmith, ldionne, dlj, mclow.lists Reviewed By: mclow.lists Subscribers: mclow.lists, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D61301 llvm-svn: 359596
* [libc++][CMake] Refactor how we link against system librariesLouis Dionne2019-04-303-40/+79
| | | | | | | | | | | | | | | | | Summary: Instead of populating the global LIBCXX_LIBRARIES, we use the link-time dependency management built into CMake to propagate link flags. This leads to a cleaner and easier-to-follow build. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, mstorsjo, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60969 llvm-svn: 359571
* Implement LWG 2960: nonesuch is insufficiently uselessMarshall Clow2019-04-304-6/+67
| | | | llvm-svn: 359526
* Mark LWG#2977 as 'Nothing to do'. NFCMarshall Clow2019-04-301-2/+2
| | | | llvm-svn: 359525
* Add tests specifically for LWG2164. We already did this; but now we have ↵Marshall Clow2019-04-293-1/+24
| | | | | | tests. NFC llvm-svn: 359458
* Fix permission error while running botsEric Fiselier2019-04-281-0/+1
| | | | llvm-svn: 359405
* attempt to unbreak build botsEric Fiselier2019-04-282-5/+7
| | | | llvm-svn: 359404
* Attempt to switch to auto-scaling botsEric Fiselier2019-04-283-0/+117
| | | | llvm-svn: 359403
* Add '_LIBCPP_ASSERT(ready())' to several match_results method that have this ↵Marshall Clow2019-04-268-13/+34
| | | | | | precondtion. Fix several tests which did not honor this precondition. Thanks to Andrey Maksimov for pointing this out. llvm-svn: 359324
* [libc++] Relax libc++-only test on regex_constantsLouis Dionne2019-04-261-13/+13
| | | | | | | | | | | | | | The standard requires the following for the std::regex_constants::error_type values: "The type error_type is an implementation-defined enumerated type." The values of this enumerated type are not required to be non-zero. This patch makes such checks in tests libc++-specific to let the tests pass for other conforming implementations. Thanks to Andrey Maksimov for the patch. Differential Revision: https://reviews.llvm.org/D61195 llvm-svn: 359320
* Fix r359229 which tried to fix r359159...Chandler Carruth2019-04-261-1/+1
| | | | | | | | When r359229 added noexcept to the declaration of `~mutex`, it didn't add it to the definition which caused -Wimplicit-exception-spec-mismatch to fire. This just adapts the definition to agree with the declaration. llvm-svn: 359275
* add tuple_cat test for const TEric Fiselier2019-04-261-6/+6
| | | | llvm-svn: 359256
* Fix return type of std::tuple_cat.Eric Fiselier2019-04-262-2/+17
| | | | | | | | | | | | When the arguments to tuple cat were const, the const was incorrectly propagated into the type of the resulting tuple. For example: const std::tuple<int> t(42); auto r = std::tuple_cat(t, t); // Incorrect! should be std::tuple<int, int>. static_assert(is_same_v<decltype(r), std::tuple<const int, const int>>); llvm-svn: 359255
* Remove incorrect explicit instantiation declarations for valarrayRichard Smith2019-04-253-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | libc++ ABI v1 provides three valarray symbols as part of the shared library: valarray<size_t>::valarray(size_t) valarray<size_t>::~valarray() valarray<size_t>::resize(size_t, size_t) The first two of these are intended to be removed in V2 of the ABI: they're attributed _LIBCPP_HIDE_FROM_ABI_AFTER_V1, and it appears that the intention is that these symbols from the library are not used even when building using the V1 ABI. However, there are explicit instantiation declarations for all three symbols in the header, which are not correct as we do not intend to find an instantiation of these functions that is provided elsewhere. (A recent change to clang to properly diagnose explicit instantiation declarations of internal linkage functions -- required by [temp.explicit]p13 -- had to be rolled back because it diagnosed these explicit instantiations.) Remove the explicit instantiation declarations, and remove the explicit instantiation definitions for V2 of the libc++ ABI onwards. llvm-svn: 359243
* Remove libc++ checks and workarounds for unsupported old versions of GCC (<4.9).Richard Smith2019-04-253-68/+39
| | | | | | Differential Revision: https://reviews.llvm.org/D61107 llvm-svn: 359232
* Fix buildbot failures after r359159.Richard Smith2019-04-251-1/+1
| | | | | | | | | | | | | std::mutex was not actually is_nothrow_default_constructible in C++98/C++03, because the variable declaration std::mutex M; ... could throw an exception from the mutex destructor. Fix it by marking the destructor as non-throwing. This has no effect in C++11 onwards, because destructors are non-throwing by default in those language modes. llvm-svn: 359229
* Set _LIBCPP_DLL_VIS on _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS in MinGW modeMartin Storsjo2019-04-251-2/+7
| | | | | | | | | | Contrary to MSVC, MinGW compilers wants the dllexport attribute on the declaration of an explicit template instantiation, not on the definition. Differential Revision: https://reviews.llvm.org/D61123 llvm-svn: 359227
* [libc++][test] Fix noexcept assertions in variant's get testsCasey Carter2019-04-253-6/+20
| | | | | | | | | | All constant expressions are non-potentially-throwing in C++14, but that is *not* the case in C++17. Change these tests of the `variant`-flavored overloads of `std::get` to expect the correct behavior when the compiler is not GCC or is GCC 9+. Credit to Jonathan Wakely for providing an improved version of my initial change that validates the incorrect behavior on GCC < 9 as well as validating the correct behavior on other compilers. Differential Revision: https://reviews.llvm.org/D61033 llvm-svn: 359220
* Implement 'lerp'; which is the last bit of P0811. Mark that paper as complete.Marshall Clow2019-04-253-1/+103
| | | | llvm-svn: 359211
* Implement midpoint for floating point types. Reviewed as ↵Marshall Clow2019-04-258-1/+228
| | | | | | https://reviews.llvm.org/D61014. llvm-svn: 359184
* Update test to better check for the non-constexpr-ness of a move ↵Marshall Clow2019-04-251-5/+20
| | | | | | constructor. Fixes PR#41577. llvm-svn: 359162
* Use modern type trait implementations when available.Richard Smith2019-04-252-14/+45
| | | | | | | | | | | | | | Teach libcxx to stop using various deprecated __has_* type traits, in favor of the ("modern", C++11 era) __is_* type traits. This is mostly just a simplification, but fixes at least one bug: _Atomic T should be considered trivially-destructible, but is not considered to be POD by Clang, and __has_trivial_destructor is specified in the GCC documentation as returning false for non-POD non-class types. Differential Revision: https://reviews.llvm.org/D48292 llvm-svn: 359159
* Add std::is_constant_evaluated.Eric Fiselier2019-04-2410-10/+103
| | | | | | | | | Clang recently added __builtin_is_constant_evaluated() and GCC 9.0 has it as well. This patch adds support for it in libc++. llvm-svn: 359119
* Make the test object callable. libstdc++'s bind checks that (libc++ ↵Marshall Clow2019-04-241-1/+1
| | | | | | currently does not). Thanks to Jonathan Wakely for the fix. llvm-svn: 359108
* Fix a one more compare test that assumed -1/0/1 instsad of <0/0/>0. NFC.Marshall Clow2019-04-241-1/+1
| | | | llvm-svn: 359106
* Fix a couple of tests that assumed that compare retunred -1/0/1 instead of ↵Marshall Clow2019-04-244-7/+7
| | | | | | <0/0/>0. Thanks to Jonathan Wakely for the report. llvm-svn: 359104
* Add an any_cast test for array types. Thanks to Jonathan Wakely for the ↵Marshall Clow2019-04-242-8/+25
| | | | | | suggestion. llvm-svn: 359085
* Avoid name conflict with kernel headersEric Fiselier2019-04-244-9/+12
| | | | llvm-svn: 359080
* [libcxx] Use relative path for libc++ library when generating scriptPetr Hosek2019-04-231-1/+4
| | | | | | | | | This addresses the issue introduced in D60309 which leads to linker scripts being generated with absolute paths. Differential Revision: https://reviews.llvm.org/D61039 llvm-svn: 359045
* Fix namespace name conflict with GCCEric Fiselier2019-04-236-55/+55
| | | | llvm-svn: 359023
* Fix implementation of ::abs and std::abs LWG 2192.Eric Fiselier2019-04-237-52/+242
| | | | | | | | | | | | | | | | | | | Summary: All overloads of `::abs` and `std::abs` must be present in both `<cmath>` and `<cstdlib>`. This is problematic to implement because C defines `fabs` in `math.h` and `labs` in `stdlib.h`. This introduces a circular dependency between the two headers. This patch implements that requirement by moving `abs` into `math.h` and making `stdlib.h` include `math.h`. In order to get the underlying C declarations from the "real" `stdlib.h` inside our `math.h` we need some trickery. Specifically we need to make `stdlib.h` include next itself. Suggestions for a cleaner implementation are welcome. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: krytarowski, fedor.sergeev, dexonsmith, jdoerfert, jsji, libcxx-commits Differential Revision: https://reviews.llvm.org/D60097 llvm-svn: 359020
* [libc++] Remove redundant conditionals for Apple platformsLouis Dionne2019-04-233-8/+6
| | | | | | | | | | | | | | | | | | | Summary: In a bunch of places, we used to check whether LIBCXX_BUILDING_LIBCXXABI is defined OR we're building for an Apple platform. This used to be necessary in a time when Apple's build script did NOT define LIBCXX_BUILDING_LIBCXXABI. However this is not relevant anymore since Apple's build does define LIBCXX_BUILDING_LIBCXXABI. Reviewers: EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60842 llvm-svn: 358988
* [libcxx] Update gen_link_script.py to support different input and outputPetr Hosek2019-04-222-62/+34
| | | | | | | | | | This enables the use of this script from other build systems like GN which don't support post-build actions as well as for static archives. Differential Revision: https://reviews.llvm.org/D60309 llvm-svn: 358915
* [libc++][test] Update some wstring_convert tests for MSVC quirksCasey Carter2019-04-223-20/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to MSVC's decision to encode `wchar_t` as UTF-16, it rejects wide character/string literals that expect a character value greater than `\xffff`. UTF-16 `wchar_t` is clearly non-conforming, given that the standard requires wchar_t to be capable of representing all characters in the supported wide character execution sets, but rejecting e.g. `\x40003` is a reasonably sane compromise given that encoding choice: there's an expectation that `\xFOO` produces a single character in the resulting literal. Consequently `L'\x40003'`/`L"\x40003"` are ill-formed literals on MSVC. `L'\U00040003'` is a high surrogate (and produces a warning about ignoring the "second character" in a multi-character literal), and `L"\U00040003"` is a perfectly-valid `const wchar_t[3]`. This change updates these tests to use universal-character-names instead of raw values for the intended character values, which technically makes them portable even to implementations that don't use a unicode transformation format encoding for their wide character execution character set. The two-character literal `L"\u1005e"` is awkward - the `e` looks like part of the UCN's hex encoding - but necessary to compile in '03 mode since '03 didn't allow UCNs to be used for members of the basic execution character set even in character/string literals. I've also eliminated the extraneous `\x00` "bonus null-terminator" in some of the string literals which doesn't affect the tested behavior. I'm sorry about using `*L"\U00040003"` in `conversions.string/to_bytes.pass.cpp`, but it's correct for platforms with 32-bit wchar_t, *and* doesn't trigger narrowing warnings as did the prior `CharT(0x40003)`. Differential Revision: https://reviews.llvm.org/D60950 llvm-svn: 358908
* [libc++] [test] Silence C++20 deprecation warnings in the MSVC STLCasey Carter2019-04-191-1/+2
| | | | | | ... when including msvc_stdlib_force_include.hpp. llvm-svn: 358782
* [libc++] Make __debug_less::operator() constexprThomas Anderson2019-04-192-0/+14
| | | | | | | | | | | | | | This is a followup to [1] which added a new `__debug_less::operator()` overload. [2] added `_LIBCPP_CONSTEXPR_AFTER_CXX17` to the original `__debug_less::operator()` between the time of writing [1] and landing it. This change adds `_LIBCPP_CONSTEXPR_AFTER_CXX17` to the new overload too. [1] https://reviews.llvm.org/rL358423 [2] https://reviews.llvm.org/rL358252 Differential Revision: https://reviews.llvm.org/D60724 llvm-svn: 358725
OpenPOWER on IntegriCloud