llvm-svn: 125311

llvm-svn: 125290

llvm-svn: 124727

llvm-svn: 124726

llvm-svn: 124508

llvm-svn: 124502

llvm-svn: 124456

llvm-svn: 124452

llvm-svn: 124432

llvm-svn: 124431

llvm-svn: 124430

Reverted previous fix to is_convertible as it caused more problems than it fixed.  But this reverted fix will only matter for non-clang compilers.  Installed __is_convertible_to for clang.

llvm-svn: 124429

testing via __has_feature, since __has_feature for C++0x features no
longer evaluates true in C++98/03 mode.

Also, eliminate the redundant using directive. Inline namespaces make
their members visible in the enclosing namespace automatically.

llvm-svn: 124293

lvalues, nor can one take the address of an xvalue, by adding
appropriate static_cast's (in the first case) and a temporary (in the
second case).

llvm-svn: 124255

llvm-svn: 124252

workaround relied on rvalue references binding to non-function
lvalues, while the original formulation (with std::forward) does the
right thing.

llvm-svn: 124241

llvm-svn: 124193

llvm-svn: 124192

result of the __tuple_leaf::get() call to an rvalue reference when
returning from tuple's get().

llvm-svn: 124190

a cv-qualifier rvalue reference to the type, e.g.,

  template <class _Tp> char  __test(const volatile typename remove_reference<_Tp>::type&&);

The use of this function signature rather than the more
straightforward one used in C++98/03 mode, e.g.,

  template <class _Tp> char  __test(_Tp);

is broken in two ways:

  1) An rvalue reference cannot bind to lvalues, so is_convertible<X&,
  X&>::value would be false. This breaks two of the unique_ptr tests
  on Clang and GCC >= 4.5. Prior GCC's seem to have allowed rvalue
  references to bind to lvalues, allowing this bug to slip in.

  2) By adding cv-qualifiers to the type we're converting to, we get
  some incorrect "true" results for, e.g., is_convertible<const X&, X&>::value.

llvm-svn: 124166

llvm-svn: 124120

constructing compile flags, and to link against the 'rt' library on
Linux for clock_gettime and friends.

llvm-svn: 124052

llvm-svn: 123392

llvm-svn: 123337

llvm-svn: 123269

Two minor fixes:  1.  Put integral_constant conversion to integral in even without constexpr support.  2.  Add ios_base to <iosfwd>.  The latter is being tracked by LWG 2026.

llvm-svn: 123080

Reverting an old optimization that conflicts with the new allocator model, and causes some test casees to compile that shouldn't.

llvm-svn: 122830

llvm-svn: 122825

llvm-svn: 122057

llvm-svn: 121655

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

The implementation of the new definition of result_of (N3123) resulted in some test failures in [func.memfn] that I failed to previously notice.  This corrects that mistake.

llvm-svn: 121600

llvm-svn: 121510

llvm-svn: 121503

llvm-svn: 121502

llvm-svn: 121282

llvm-svn: 121275

After a long break to wait for the atomic spec to settle, this completes the library part of <atomic>.  It currently won't even parse as it depends on the existence of the intrinsics specified at http://libcxx.llvm.org/atomic_design_a.html.  Everything has been tested using fake intrinsics which have now been removed.  As the intrinsics come online, the ATOMIC_* macros will need to be adjusted to reflect which operations are lock-free.  These macros will probably need to be #ifdef'd for each supported platform.

llvm-svn: 121267

llvm-svn: 121265

llvm-svn: 121204