Howard Hinnant
|
f3b02b17af
|
Accidentally disallowed explicit tuple conversions when all elements of the tuple can be explicitly converted.
llvm-svn: 179467
|
2013-04-14 00:01:13 +00:00 |
Howard Hinnant
|
6e41256f68
|
No functionality change at this time. I've split _LIBCPP_VISIBLE up into 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
|
2013-03-06 23:30:19 +00:00 |
Howard Hinnant
|
54d333a601
|
Rename uses of _ and __ because these are getting stepped on by macros from other system code.
llvm-svn: 167038
|
2012-10-30 19:06:59 +00:00 |
Howard Hinnant
|
aeb85680fb
|
Dimitry Andric: many visibility fixes. Howard: Much appreciated. Can you send me a patch to CREDITS.TXT?
llvm-svn: 163862
|
2012-09-14 00:39:16 +00:00 |
Howard Hinnant
|
c0937e8add
|
Appy constexpr to <memory>. Picked up a few missing noexcepts as well.
llvm-svn: 159902
|
2012-07-07 20:56:04 +00:00 |
Howard Hinnant
|
8a9ee14803
|
Apply noexcept to tuple.
llvm-svn: 159865
|
2012-07-06 21:53:48 +00:00 |
Howard Hinnant
|
a0f4c45c38
|
As a conforming extension give tuple a noexcept default constructor conditionalized on its held types.
llvm-svn: 159858
|
2012-07-06 20:50:27 +00:00 |
Howard Hinnant
|
a62ebe043e
|
Give tuple a constexpr default constructor.
llvm-svn: 159857
|
2012-07-06 20:39:45 +00:00 |
Howard Hinnant
|
0527c6207a
|
I believe tuple is still under development in the standard. Daniel Krugler is/will be making convincing arguments that a modified form of LWG 2051 (currently NAD Future) is easily acheivable and desirable. He has demonstrated that a tuple<T...> where all of the T are implicitly convertible from U... should have a tuple constructor that is also implicit, instead of explicit. This would support the use cases in LWG 2051 while not undermining T... with explicit conversions from U.... This check-in is an experimental implementation of Daniel's work. I believe this work to be mature enough to warrant inclusion into libc++. If anyone sees real-world problems that this check in causes, please let me know and I will revert it, and provide the feedback to the LWG.
llvm-svn: 153855
|
2012-04-01 23:10:42 +00:00 |
Howard Hinnant
|
fa8df7db88
|
tuple was accidentally lacking a valid copy assignment operator. It went undetected because I had failed to test assigning from a const lvalue. This fixes http://llvm.org/bugs/show_bug.cgi?id=11921
llvm-svn: 150613
|
2012-02-15 20:13:52 +00:00 |
Howard Hinnant
|
a87b5e3446
|
Fix http://llvm.org/bugs/show_bug.cgi?id=11616
llvm-svn: 146881
|
2011-12-19 17:58:44 +00:00 |
Howard Hinnant
|
42b8bb5033
|
Fix http://llvm.org/bugs/show_bug.cgi?id=11461. Credit Alberto Ganesh Barbati.
llvm-svn: 146345
|
2011-12-11 20:31:33 +00:00 |
Howard Hinnant
|
c206366fd7
|
Quash a whole bunch of warnings
llvm-svn: 145624
|
2011-12-01 20:21:04 +00:00 |
Howard Hinnant
|
c003db1fca
|
Further macro protection by replacing _[A-Z] with _[A-Z]p
llvm-svn: 145410
|
2011-11-29 18:15:50 +00:00 |
Howard Hinnant
|
073458b1ab
|
Windows support by Ruben Van Boxem.
llvm-svn: 142235
|
2011-10-17 20:05:10 +00:00 |
Howard Hinnant
|
1e31e53fe1
|
Fix <rdar://problem/10226704>
llvm-svn: 141054
|
2011-10-04 01:25:20 +00:00 |
Howard Hinnant
|
ce48a1137d
|
_STD -> _VSTD to avoid macro clash on windows
llvm-svn: 134190
|
2011-06-30 21:18:19 +00:00 |
Howard Hinnant
|
bc95cf0d5f
|
Experimental support for a meaningful __is_swappable<T>::value. This does not appear to be strictly needed for correct functioning of the library. If it causes any problems, I'd rather pull it sooner rather than later.
llvm-svn: 132421
|
2011-06-01 19:59:32 +00:00 |
Howard Hinnant
|
27d0a2a75d
|
noexcept for <tuple>. And in the process learned that I had done it wrong for pair's swap. I needed to create an __is_nothrow_swappable<T>::value trait that was smart enought to answer false when __is_swappable<T>::value is false. Otherwise one gets compile-time errors when using pair or tuple of non-swappable types, even if you never try to swap the pair or tuple.
llvm-svn: 132204
|
2011-05-27 19:08:18 +00:00 |
Howard Hinnant
|
2a3f1bc13f
|
tweak for readability (no functionality change)
llvm-svn: 124192
|
2011-01-25 16:31:30 +00:00 |
Douglas Gregor
|
912e161ce0
|
An rvalue reference cannot bind to an lvalue, so static_cast the
result of the __tuple_leaf::get() call to an rvalue reference when
returning from tuple's get().
llvm-svn: 124190
|
2011-01-25 16:14:21 +00:00 |
Howard Hinnant
|
465abe92a5
|
Chandler Carruth changed >> to > > in several places.
llvm-svn: 124120
|
2011-01-24 16:07:25 +00:00 |
Howard Hinnant
|
ba31cbdbca
|
Reduced copying cost of tuple_cat from quadratic to linear.
llvm-svn: 121655
|
2010-12-12 23:04:37 +00:00 |
Howard Hinnant
|
7f64810bc8
|
LWG 1385 [FCD] tuple_cat should be a single variadic signature (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1385). This issue is only in Ready status, meaning it is not official, but probably will be this March in Madrid. It was tentatively accepted in Batavia with the previso that Bill and I didn't have any problems implementing it. This is my part of that agreement.
llvm-svn: 121619
|
2010-12-11 20:47:50 +00:00 |
Howard Hinnant
|
601afb30ec
|
LWG 1191
llvm-svn: 119545
|
2010-11-17 19:52:17 +00:00 |
Howard Hinnant
|
ef6168357a
|
LWG 1118
llvm-svn: 119541
|
2010-11-17 19:22:43 +00:00 |
Howard Hinnant
|
30ad985b6b
|
Cleaning up some tuple code.
llvm-svn: 114848
|
2010-09-27 17:54:17 +00:00 |
Howard Hinnant
|
789847ddbb
|
visibility-decoration sweep completed.
llvm-svn: 114685
|
2010-09-23 18:58:28 +00:00 |
Howard Hinnant
|
b3371f6f49
|
Fixing whitespace problems
llvm-svn: 111750
|
2010-08-22 00:02:43 +00:00 |
Howard Hinnant
|
907af2668f
|
GB 85, GB 87
llvm-svn: 111546
|
2010-08-19 19:15:54 +00:00 |
Howard Hinnant
|
1102fbbd67
|
US 98, US 99
llvm-svn: 111542
|
2010-08-19 18:59:38 +00:00 |
Howard Hinnant
|
5b08a8a432
|
Wiped out some non-ascii characters that snuck into the copyright.
llvm-svn: 103516
|
2010-05-11 21:36:01 +00:00 |
Howard Hinnant
|
3e519524c1
|
libcxx initial import
llvm-svn: 103490
|
2010-05-11 19:42:16 +00:00 |