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
..
UTypes.fail.cpp	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.	2012-04-01 23:10:42 +00:00
UTypes.pass.cpp	license change	2010-11-16 22:09:02 +00:00
alloc.pass.cpp	license change	2010-11-16 22:09:02 +00:00
alloc_UTypes.pass.cpp	license change	2010-11-16 22:09:02 +00:00
alloc_const_Types.pass.cpp	license change	2010-11-16 22:09:02 +00:00
alloc_const_pair.pass.cpp	license change	2010-11-16 22:09:02 +00:00
alloc_convert_copy.pass.cpp	license change	2010-11-16 22:09:02 +00:00
alloc_convert_move.pass.cpp	license change	2010-11-16 22:09:02 +00:00
alloc_copy.pass.cpp	license change	2010-11-16 22:09:02 +00:00
alloc_move.pass.cpp	license change	2010-11-16 22:09:02 +00:00
alloc_move_pair.pass.cpp	license change	2010-11-16 22:09:02 +00:00
const_Types.fail.cpp	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.	2012-04-01 23:10:42 +00:00
const_Types.pass.cpp	license change	2010-11-16 22:09:02 +00:00
const_Types2.fail.cpp	license change	2010-11-16 22:09:02 +00:00
const_pair.pass.cpp	license change	2010-11-16 22:09:02 +00:00
convert_copy.pass.cpp	Accidentally disallowed explicit tuple conversions when all elements of the tuple can be explicitly converted.	2013-04-14 00:01:13 +00:00
convert_move.pass.cpp	license change	2010-11-16 22:09:02 +00:00
copy.fail.cpp	license change	2010-11-16 22:09:02 +00:00
copy.pass.cpp	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	2012-02-15 20:13:52 +00:00
default.pass.cpp	Give tuple a constexpr default constructor.	2012-07-06 20:39:45 +00:00
move.pass.cpp	license change	2010-11-16 22:09:02 +00:00
move_pair.pass.cpp	license change	2010-11-16 22:09:02 +00:00