Summary:
Hi Marshall,
Could you please test this patch and see if you run into the same linker errors we talked about?
I can't reproduce on linux or OS X.
Hopefully you can't find any problems and we can fix the C++03 bot.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13337
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@249192 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In rL241532, atomic_support.h was added, which provides handling of
atomic operations for libc++. When atomic builtins are not available,
it emits a warning about being unsupported, but it still provides a
number of stubs for the required functions.
However, it misses a stub for `__libcpp_relaxed_store()`. Add it, by
using the same implementation as for `__libcpp_atomic_store()`.
(Note that I encountered this on arm-freebsd, which still defaults to
armv4, and does not have the runtime libcalls to support atomic
builtins. For now, I have simply disabled using them.)
Reviewers: mclow.lists, EricWF
Subscribers: theraven, cfe-commits, jroelofs, majnemer, aemerson
Differential Revision: http://reviews.llvm.org/D13051
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@248313 91177308-0d34-0410-b5e6-96231b3b80d8
After months of work there are only 4 tests still failing in C++03.
This patch fixes those tests.
All of the libc++ builders should be green.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@246275 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch properly constrains the converting assignment operator in C++03. It also fixes a bug where std::forward was given the wrong type.
The following two tests begin passing in C++03:
* `unique_ptr.single.asgn/move_convert.pass.cpp`
* `unique_ptr.single.asgn/move_convert13.fail.cpp`
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12173
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@246272 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`.
It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header.
@mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03?
Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`.
Reviewers: mclow.lists
Subscribers: vsk, mclow.lists, cfe-commits
Differential Revision: http://reviews.llvm.org/D12135
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@246271 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
On Mac OS X overwriting `/usr/lib/libc++.dylib` can cause your computer to fail to boot. This patch tries to make it harder to do that accidentally.
If `CMAKE_SYSTEM_NAME` is `Darwin` and `CMAKE_INSTALL_PREFIX` is `/usr` don't generate installation rules unless the user explicitly provides `LIBCXX_OVERRIDE_DARWIN_INSTALL=ON`. Note that `CMAKE_INSTALL_PREFIX` is always absolute so we don't need to worry about things like `/usr/../usr`.
Reviewers: mclow.lists, beanz, jroelofs
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12209
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@246070 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Detecting `-Wno-<warning>` flags can be tricky with GCC (See https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html). This patch adds a special `addWarningFlagIfSupported(<flag>)` method to the test compiler object that can be used to add warning flags. The goal of this patch is to help get the test suite running with more warnings.
Reviewers: danalbert, jroelofs
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11333
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@246069 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@246068 91177308-0d34-0410-b5e6-96231b3b80d8
