summaryrefslogtreecommitdiffstats
path: root/libcxx/include/__functional_base
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Take 2: Implement LWG 2510Louis Dionne2019-09-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: LWG2510 makes tag types like allocator_arg_t explicitly default constructible instead of implicitly default constructible. It also makes the constructors for std::pair and std::tuple conditionally explicit based on the explicit-ness of the default constructibility for the pair/tuple's elements. This was previously committed as r372777 and reverted in r372832 due to the commit breaking LLVM's build in C++14 mode. This issue has now been addressed. Reviewers: mclow.lists Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65161 llvm-svn: 372983
* Revert r372777: [libc++] Implement LWG 2510 and its follow-upsIlya Biryukov2019-09-251-1/+1
| | | | | | | | | | | | This also reverts: - r372778: [libc++] Implement LWG 3158 - r372782: [libc++] Try fixing tests that fail on GCC 5 and older - r372787: Purge mentions of GCC 4 from the test suite Reason: the change breaks compilation of LLVM with libc++, for details see http://lists.llvm.org/pipermail/libcxx-dev/2019-September/000599.html llvm-svn: 372832
* [libc++] Implement LWG 2510Louis Dionne2019-09-241-1/+1
| | | | | | | | | | | | | | | | | | | Summary: LWG2510 makes tag types like allocator_arg_t explicitly default constructible instead of implicitly default constructible. It also makes the constructors for std::pair and std::tuple conditionally explicit based on the explicit-ness of the default constructibility for the pair/tuple's elements. Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65161 llvm-svn: 372777
* Apply [[nodebug]] to typedefs throughout the STL.Eric Fiselier2019-06-121-5/+5
| | | | | | | | | | | | | | | | When applied to a typedef or alias template, the [[nodebug]] attribute makes the typedef transparent to the debugger, so instead of seeing `std::__function::__alloc_func<remove_reference<void(&)()>::type, allocator<remove_reference<void(&)()>, void()>::_Target` you see `void(&)()` as the type of the variable in your debugger. Removing all this SFINAE noise from debug info has huge binary size wins, in addition to improving the readability. For now this change is on by default. Users can override it by specifying -D_LIBCPP_NODEBUG_TYPE= llvm-svn: 363117
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | | to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
* [libc++] Make sure we can build libc++ with -fvisibility=hiddenLouis Dionne2018-10-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When building with -fvisibility=hidden, some symbols do not get exported from libc++.dylib. This means that some entities are not explicitly given default visibility in the source code, and that we rely on the fact -fvisibility=default is the default. This commit explicitly gives default visibility to those symbols to avoid being dependent on the command line flags used. The commit also remove symbols from the dylib -- those symbols do not actually need to be exported from the dylib and this should not be an ABI break. Finally, in the future, we may want to mark the whole std:: namespace as having hidden visibility (to switch from opt-out to opt-in), in which case the changes done in this commit will be required. Reviewers: EricWF Subscribers: mgorny, christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D52662 llvm-svn: 345260
* [libc++] Add deprecated attributes to many deprecated componentsLouis Dionne2018-09-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: These deprecation warnings are opt-in: they are only enabled when the _LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case by default. Note that this is a first step in the right direction, but I wasn't able to get an exhaustive list of all deprecated components per standard, so there's certainly stuff that's missing. The list of components this commit marks as deprecated is: in C++11: - auto_ptr, auto_ptr_ref - binder1st, binder2nd, bind1st(), bind2nd() - pointer_to_unary_function, pointer_to_binary_function, ptr_fun() - mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun() - mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref() in C++14: - random_shuffle() in C++17: - unary_negate, binary_negate, not1(), not2() <rdar://problem/18168350> Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D48912 llvm-svn: 342843
* [libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since ↵Louis Dionne2018-08-011-1/+1
| | | | | | | | | | | | | | _LIBCPP_BUILDING_LIBRARY Summary: As suggested by Marshall in https://reviews.llvm.org/D49914 Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50008 llvm-svn: 338475
* Remove unused code from __functional_base. NFC.Eric Fiselier2018-06-061-10/+0
| | | | | | | | | | | | | | Patch from Arthur O'Dwyer. `__user_alloc_construct_impl` is used by <experimental/memory_resource>, but this `__user_alloc_construct` is never used. Also, `<experimental/memory_resource>` doesn't need a full definition of `std::tuple`; just the forward declaration in `<__tuple>` will suffice. Reviewed as https://reviews.llvm.org/D46806 llvm-svn: 334069
* Un-inline a few more variables that are exported from the dylib.Marshall Clow2018-01-021-1/+1
| | | | llvm-svn: 321664
* Implement most of P0607: Inline Variables for the Standard Library. This ↵Marshall Clow2018-01-021-2/+2
| | | | | | involved marking a lot of variables as inline (but only for C++17 and later). llvm-svn: 321658
* Fix bug 33389 - __is_transparent check requires too muchMarshall Clow2017-06-131-10/+7
| | | | llvm-svn: 305292
* Cleanup remaining usages of _LIBCPP_HAS_NO_<c++11-feature> in the functional ↵Eric Fiselier2017-04-191-13/+9
| | | | | | library llvm-svn: 300646
* Implement P0513R0 - "Poisoning the Hash"Eric Fiselier2017-01-211-7/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Exactly what the title says. This patch also adds a `std::hash<nullptr_t>` specialization in C++17, but it was not added by this paper and I can't find the actual paper that adds it. See http://wg21.link/P0513R0 for more info. If there are no comments in the next couple of days I'll commit this Reviewers: mclow.lists, K-ballo, EricWF Reviewed By: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28938 llvm-svn: 292684
* Replace _LIBCPP_HAS_NO_DELETED_FUNCTIONS with _LIBCPP_CXX03_LANGEric Fiselier2017-01-061-15/+2
| | | | llvm-svn: 291278
* [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VISEric Fiselier2017-01-041-7/+7
| | | | | | | | | | | | | The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both _LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to __attribute__((__type_visibility__)) with Clang. The only remaining difference is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas _LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on templates). This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS. llvm-svn: 291035
* [libcxx] Fix PR24075, PR23841 - Add ↵Eric Fiselier2016-12-141-1/+5
| | | | | | | | | | | | | | | | | | | | scoped_allocator_adaptor::construct(pair<T, U>*, ...) overloads. Summary: For more information see: * https://llvm.org/bugs/show_bug.cgi?id=23841 * https://llvm.org/bugs/show_bug.cgi?id=24075 I hope you have as much fun reviewing as I did writing these insane tests! Reviewers: mclow.lists, AlisdairM, EricWF Subscribers: AlisdairM, Potatoswatter, cfe-commits Differential Revision: https://reviews.llvm.org/D27612 llvm-svn: 289710
* Add missing _v traits. is_bind_expression_v, is_placeholder_v and ↵Marshall Clow2016-09-221-0/+5
| | | | | | uses_allocator_v llvm-svn: 282126
* Fix most GCC attribute ignored warningsEric Fiselier2016-04-211-2/+0
| | | | llvm-svn: 267074
* Add 'is_callable' and 'is_nothrow_callable' traits and cleanup INVOKE.Eric Fiselier2016-04-201-81/+3
| | | | | | | | | | | | The primary purpose of this patch is to add the 'is_callable' traits. Since 'is_nothrow_callable' required making 'INVOKE' conditionally noexcept I also took this oppertunity to implement a constexpr version of INVOKE. This fixes 'std::experimental::apply' which required constexpr 'INVOKE support'. This patch will be followed up with some cleanup. Primarly removing most of "__member_function_traits" since it's no longer used by INVOKE (in C++11 at least). llvm-svn: 266836
* Implement LWG issue 2219 - support reference_wrapper in INVOKEEric Fiselier2016-04-181-4/+22
| | | | llvm-svn: 266590
* Fix a corner case that involved calling rethrow_if_nested with a type that ↵Marshall Clow2015-12-141-51/+0
| | | | | | had a deleted operator&. Added a test to catch this as well. Thanks to Ville for the heads-up. llvm-svn: 255517
* [libcxx] Rewrite C++03 __invoke.Eric Fiselier2015-08-261-28/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch rewrites the C++03 `__invoke` and related meta-programming. There are a number of major changes. `__invoke` in C++03 now has a fallback overload for when the invoke expression is ill-formed (similar to C++11). This means that the `__invoke_return` traits will return `__nat` when `__invoke(...)` is ill formed. This would previously cause a compile error. Bullets 1-4 of `__invoke` have been rewritten. In the old version `__invoke` had 32 overloads for bullets 1 and 2, one for each possible cv-qualified function signature with arities 0-3. 64 overloads would be needed to support member functions with varargs. Currently these overloads were fundamentally broken. An example overload looked like: ``` template <class Rp, class Tp, class T1, class A0> Rp __invoke(Rp (Tp::*pm)(A0) const, T1&, A0&) ``` Because `A0` appeared in two different deducible contexts it would have to deduce to be an exact match or the overload would be rejected. This is made even worse because `A0` appears without a reference qualifier in the member function signature and with a reference qualifier as an `__invoke` parameter. This means that only member functions that took all of their arguments by value could be matched. One possible fix would be to make the second occurrence of `A0` appear in a non-deducible context. This way any type convertible to `A0` could be passed as the first parameter. The benefit of this approach is that the signature of the member function enforces the arity and types taken by the `__invoke` signature it generates. However nothing in the `INVOKE` specification requires this behavior. My solution is to use a `__invoke_enable_if<PM_Type, Tp>` metafunction to selectively enable the `__invoke` overloads for bullets 1, 2, 3 and 4. It uses `__member_function_traits` to inspect and extract the return type and class type of the pointer to member. Using `__member_function_traits` to inspect `PM_Type` also allows us to reduce the number of `__invoke` overloads from 32 to 8 and add varargs support at the same time. Because `__invoke_enable_if` knows the exact return type of `__invoke` for bullets 1-4 we no longer need to use `decltype(__invoke(...))` to compute the return type in the `__invoke_return*` traits. This will reduce the problems caused by `#define decltype(X) __typeof__(X)` in C++03. Tests for this change have already been committed. All tests in `test/std/utilities/function.objects` now pass in C++03, previously there were 20 failures. Reviewers: K-ballo, howard.hinnant, mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11553 llvm-svn: 246068
* Remove almost everything in <__functional_base_03>Eric Fiselier2015-07-221-10/+94
| | | | | | | | | This patch removes a large amount of duplicate code found in both <__functional_base> and <__functional_base_03>. The only code that remains in <__functional_base_03> is the C++03 implementation of __invoke and __invoke_return. llvm-svn: 242951
* Remove constexpr support for std::apply because it introduces regressions.Eric Fiselier2015-04-191-5/+5
| | | | llvm-svn: 235274
* [libcxx] Add <experimental/tuple> header for LFTS.Eric Fiselier2015-03-171-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the `<experimental/tuple>` header (almost) as specified in the latest draft of the library fundamentals TS. The main changes in this patch are: 1. Added variable template `tuple_size_v` 2. Added function `apply(Func &&, Tuple &&)`. 3. Changed `__invoke` to be `_LIBCPP_CONSTEXPR_AFTER_CXX11`. The `apply(...)` implementation uses `__invoke` to invoke the given function. `__invoke` already provides the required functionality. Using `__invoke` also allows `apply` to be used on pointers to member function/objects as an extension. In order to facilitate this `__invoke` has to be marked `constexpr`. Test Plan: Each new feature was tested. The test cases for `tuple_size_v` are as follows: 1. tuple_size_v.pass.cpp - Check `tuple_size_v` on cv qualified tuples, pairs and arrays. 2. tuple_size_v.fail.cpp - Test on reference type. 3. tuple_size_v_2.fail.cpp - Test on non-tuple 4. tuple_size_v_3.fail.cpp - Test on pointer type. The test cases for tuple.apply are as follows: 1. arg_type.pass.cpp - Ensure that ref/pointer/cv qualified types are properly passed. 2. constexpr_types.pass.cpp - Ensure constexpr evaluation of apply is possible for `tuple` and `pair`. 3. extended_types.pass.cpp - Test apply on function types permitted by extension. 4. large_arity.pass.cpp - Test that apply can evaluated on tuples and arrays with large sizes. 5. ref_qualifiers.pass.cpp - Test that apply respects ref qualified functions. 6. return_type.pass.cpp - Test that apply returns the proper type. 7. types.pass.cpp - Test apply on function types as required by LFTS. Reviewers: mclow.lists Reviewed By: mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D4512 llvm-svn: 232515
* Add trailing return types (and noexcept specifications) to the 'diamond ↵Marshall Clow2015-02-251-1/+3
| | | | | | operators'. Fixes PR#22600. llvm-svn: 230484
* [libcxx] Fix PR 22468 - std::function<void()> does not accept ↵Eric Fiselier2015-02-101-0/+20
| | | | | | | | | | | | | | | | | | | non-void-returning functions Summary: The bug can be found here: http://llvm.org/bugs/show_bug.cgi?id=22468 `__invoke_void_return_wrapper` is needed to properly handle calling a function that returns a value but where the std::function return type is void. Without this '-Wsystem-headers' will cause `function::operator()(...)` to not compile. Reviewers: eugenis, K-ballo, mclow.lists Reviewed By: mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7444 llvm-svn: 228705
* Rename several internal templates to get rid of ___ (triple underscores) or ↵Marshall Clow2014-01-061-3/+3
| | | | | | worse, four. No functionality change. llvm-svn: 198608
* Implement n3789; constexpr support in named function objectsMarshall Clow2013-09-281-2/+4
| | | | llvm-svn: 191626
* Implement uses-allocator constructionMarshall Clow2013-09-121-0/+92
| | | | llvm-svn: 190571
* First half of support for N3657; heterogenous lookups for set/multisetMarshall Clow2013-08-131-0/+15
| | | | llvm-svn: 188241
* Nico Rieck: this patch series fixes visibility issues on Windows as ↵Howard Hinnant2013-08-121-6/+6
| | | | | | explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
* My previous reorganization of addressof broke -std=c++03. Thanks much to ↵Howard Hinnant2013-08-081-1/+52
| | | | | | Arnold Schwaighofer for catching this. This patch also catches a few more missing addressof in <future>, thanks go to Zhihao Yuan for catching these. llvm-svn: 187997
* Revert r187927.Arnold Schwaighofer2013-08-081-52/+1
| | | | | | | | Zhihao Yuan: Replace operator& with addressof in reference_wrapper constructor. It breaks a clang bootstrap. llvm-svn: 187959
* Zhihao Yuan: Replace operator& with addressof in reference_wrapper constructor.Howard Hinnant2013-08-071-1/+52
| | | | llvm-svn: 187927
* Implement N3421; comparison predicates<void>Marshall Clow2013-07-291-0/+14
| | | | llvm-svn: 187357
* Constrain __invoke functions more accurately. This fixes ↵Howard Hinnant2013-05-071-4/+8
| | | | | | http://llvm.org/bugs/show_bug.cgi?id=15861 . llvm-svn: 181377
* No functionality change at this time. I've split _LIBCPP_VISIBLE up into ↵Howard Hinnant2013-03-061-5/+5
| | | | | | two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS. This is in preparation for taking advantage of clang's new __type_visibility__ attribute. llvm-svn: 176593
* Rename uses of _ and __ because these are getting stepped on by macros from ↵Howard Hinnant2012-10-301-3/+3
| | | | | | other system code. llvm-svn: 167038
* Modernize relational operators for shared_ptr and unique_ptr. This includes ↵Howard Hinnant2012-02-211-0/+7
| | | | | | adding support for nullptr, and using less<T*>. Fixes http://llvm.org/bugs/show_bug.cgi?id=12056. llvm-svn: 151084
* Quash a whole bunch of warningsHoward Hinnant2011-12-011-4/+4
| | | | llvm-svn: 145624
* Further macro protection by replacing _[A-Z] with _[A-Z]pHoward Hinnant2011-11-291-90/+90
| | | | llvm-svn: 145410
* Windows support by Ruben Van Boxem.Howard Hinnant2011-10-171-0/+2
| | | | llvm-svn: 142235
* _STD -> _VSTD to avoid macro clash on windowsHoward Hinnant2011-06-301-12/+12
| | | | llvm-svn: 134190
* noexcept for <functional>.Howard Hinnant2011-05-281-7/+7
| | | | llvm-svn: 132264
* This is a simplified (and superior) implementation of __invoke, __invokable ↵Howard Hinnant2011-05-201-145/+31
| | | | | | and __invoke_of. It is superior in that __invoke now handles reference qualified member functions whereas the previous implementation did not. And it simply has less infrastructure in its implementation. I'm still learning how to program in C++11 (and probably will be for a long time). This change does not impact the behavior we're seeing in http://llvm.org/bugs/show_bug.cgi?id=9975 llvm-svn: 131761
* I had a giant misunderstanding of what 'synchronizes with' meant in ↵Howard Hinnant2011-05-191-2/+2
| | | | | | [futures.async]/p5. This invalidated the current design of async in <future>. This is a new design, based on my new understanding, which has been confirmed on the lwg mailing list. The summary is that ~future() (and ~shared_future()) will block when they are created from within async, and the thread hasn't finished yet. As part of this work I created two new type traits: __invokable<F, Args...>::value and __invoke_of<F, Args...>::type. These are what result_of<F(Args...)> wanted to be when it grew up, but never will be. __invoke_of is carefully crafted so that it can serve as its own enable_if (type doesn't exist if the signature isn't invokable). All of this work is C++11 only. llvm-svn: 131639
* Spit 5th bullet __invoke into function pointers and everything else because ↵Howard Hinnant2011-05-161-0/+8
| | | | | | result_of doesn't deal with function pointers. llvm-svn: 131409
* license changeHoward Hinnant2010-11-161-2/+2
| | | | llvm-svn: 119395
OpenPOWER on IntegriCloud