llvm-svn: 158172

llvm-svn: 157832

llvm-svn: 157779

llvm-svn: 157765

llvm-svn: 157764

The rules for emplace in map, multimap, unordered_map and unordered_multimap changed a while back and I'm just now updating to these new rules.  In a nutshell, you've got to know you're emplacing to a pair and use one of pair's constructors.  I made one extension:  If you want to emplace the key and default construct the mapped_type, you can just emplace(key), as opposed to emplace(piecewise_construct, forward_as_tuple(key), forward_as_tuple()).

llvm-svn: 157503

llvm-svn: 157476

llvm-svn: 157157

Revert fix to http://llvm.org/bugs/show_bug.cgi?id=12867 for the reason now included in the code comment.

llvm-svn: 157128

llvm-svn: 157108

llvm-svn: 157107

functions to the original declarations, so that Clang will actually
see them. Part of <rdar://problem/11489333>.

llvm-svn: 157097

Protect __shared_weak_count::__get_deleter declaration with _LIBCPP_NO_RTTI.  Fixes http://llvm.org/bugs/show_bug.cgi?id=12867

llvm-svn: 157049

llvm-svn: 156546

llvm-svn: 156543

SFINAE __bit_iterator such that it will only get instantiated with a container that has the nested type __storage_type.  This prevents accidental instantiation such as in http://llvm.org/bugs/show_bug.cgi?id=12755.  This fixes http://llvm.org/bugs/show_bug.cgi?id=12755.

llvm-svn: 156308

Constrain __bind functor constructor such that it won't accidentally get used as a copy constructor from a non-const lvalue.  Fixes <rdar://problem/11359080>.

llvm-svn: 156182

llvm-svn: 156064

Greatly scale back ambitions of emulating move semantics in C++03 mode.  It was causing more problems than it solved.  This fixes http://llvm.org/bugs/show_bug.cgi?id=12704.

llvm-svn: 155918

out of the box on Linux systems. If you're building against libc++abi, you
still need to make sure it can find <cxxabi.h> so it knows not to export
symbols which libc++abi provides.

llvm-svn: 155091

at the moment, but they allow these tests to be used to test clang against
libstdc++. Add myself to the credits file, as suggested by Howard.

llvm-svn: 155085

llvm-svn: 154526

Per discussion with Howard, we are not interested in maintaining
compatibility with older versions of clang.

All tests pass with ToT clang, except for two which assert due to
a pre-existing, unrelated bug.

llvm-svn: 154521

initialisation, do the right thing with regard to atomic initialisation.

Note: clang r154507 or later required for <atomic> to work now.
llvm-svn: 154508

compare-and-exchange failed (it should update the expected value to the current
value, and the tests were checking that it didn't...).

Results of the atomics part of the test suite on FreeBSD with clang trunk and
the atomic.c from compiler-rt (currently kludged into the test, not installed
properly):

****************************************************
Results for /root/libc++/test/atomics:
using clang version 3.1 (trunk 153415)
Target: x86_64-unknown-freebsd10.0
Thread model: posix
with -std=c++0x -stdlib=libc++ -pthread /tmp/atomic.o  
----------------------------------------------------
sections without tests   : 0
sections with failures   : 0
sections without failures: 14
                       +   ----
total number of sections : 14
----------------------------------------------------
number of tests failed   : 0
number of tests passed   : 52
                       +   ----
total number of tests    : 52
****************************************************

Yay!

llvm-svn: 154095

Now all of the test cases compile.  Some of them even run!

llvm-svn: 154094

llvm-svn: 154093

Put std::piecewise_construct_t back into the dylib for ABI stability.  When clients are in C++11/constexpr mode this will be safely ignored because piecewise_construct is then declared with internal linkage.

llvm-svn: 153981

llvm-svn: 153968

llvm-svn: 153955

llvm-svn: 153896

llvm-svn: 153888

Fix test for default constructor of discrete_distribution.  This partially addresses http://llvm.org/bugs/show_bug.cgi?id=12436.

llvm-svn: 153873

This is an initial commit of constexpr support as proposed by Richard Smith.  This by no means completes constexpr support.  Indeed, it hardly scratches the surface.  All it does is lay the foundation in <__config> and changes those few places in the library that are already using that foundation.

llvm-svn: 153856

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

It appears that the standard accidentally removed the default constructor for error_category.  I'm putting it back in.  This fixes http://llvm.org/bugs/show_bug.cgi?id=12321.

llvm-svn: 153194

Allow libc++ to be built with CMake from within the LLVM tree. The libc++ part is just some renaming as the variable  was already in use, conflicting with something else in the LLVM tree.  Contributed by Ruben Van Boxem.

llvm-svn: 153036

Alter the terminal streams such that they do not get added to the atexit chain, and thus never get destructed.

llvm-svn: 152926

llvm-svn: 152718

llvm-svn: 152717