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.
llvm-svn: 246275
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
llvm-svn: 246271
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
llvm-svn: 246068
Currently we need an #ifdef branch every time we use pointer traits to rebind a pointer because
it is done differently in C++11 and C++03. This patch introduces the __rebind_pointer utility to
clean this up.
Also add a test that list and it's iterators can be instantiated with incomplete element types.
llvm-svn: 245806
First I removed all of the uses of _LIBCPP_STD_VER and added LIT UNSUPPORTED tags to prevent the tests from being run in older standard dialects.
Second I increased the time tolerances used in some tests when testing with Thread Sanitizer because thread sanitizer make these tests take longer.
llvm-svn: 245793
Because <atomic> can now be used in C++03 there is no need for the test_atomic.h header.
This commit removes the header and converts all usages to use <atomic> instead.
llvm-svn: 245468
Summary:
After putting this question up on cfe-dev I have decided that it would be best to allow the use of `<atomic>` in C++03. Although static initialization is a concern the syntax required to get it is C++11 only. Meaning that C++11 constant static initialization cannot silently break in C++03, it will always cause a syntax error. Furthermore `ATOMIC_VAR_INIT` and `ATOMIC_FLAG_INIT` remain defined in C++03 even though they cannot be used because C++03 usages will cause better error messages.
The main change in this patch is to replace `__has_feature(cxx_atomic)`, which only returns true when C++ >= 11, to `__has_extension(c_atomic)` which returns true whenever clang supports the required atomic builtins.
This patch adds the following macros:
* `_LIBCPP_HAS_C_ATOMIC_IMP` - Defined on clang versions which provide the C `_Atomic` keyword.
* `_LIBCPP_HAS_GCC_ATOMIC_IMP` - Defined on GCC > 4.7. We must use the fallback atomic implementation.
* `_LIBCPP_HAS_NO_ATOMIC_HEADER` - Defined when it is not safe to include `<atomic>`.
`_LIBCPP_HAS_C_ATOMIC_IMP` and `_LIBCPP_HAS_GCC_ATOMIC_IMP` are mutually exclusive, only one should be defined. If neither is defined then `<atomic>` is not implemented and including `<atomic>` will issue an error.
Reviewers: chandlerc, jroelofs, mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11555
llvm-svn: 245463
std::packaged_task requires variadic templates and is #ifdef out in C++03.
This patch silences the tests in C++03. This patch also rewrites the .fail.cpp tests so that they use clang verify.
llvm-svn: 245413
Summary:
This patch attempts to fix the last 3 TSAN failures on the libc++ bot (http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-tsan/builds/143). This patch also adds a `Atomic` test type that can be used where `<atomic>` cannot.
`wait.exception.pass.cpp` and `wait_for.exception.pass.cpp` were failing because the test replaced `std::terminate` with `std::exit`. `std::exit` would asynchronously run the TLS and static destructors and this would cause a race condition. See PR22606 and D8802 for more details.
This is fixed by using `_Exit` to prevent cleanup.
`notify_all_at_thread_exit.pass.cpp` exercises the same race condition but for different reasons. I fixed this test by manually joining the thread before beginning program termination.
Reviewers: EricWF, mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11046
llvm-svn: 245389
Summary:
This patch fixes __not_null's detection of nullptr by breaking it down into 4 cases.
1. `__not_null(Tp const&)`: Default case. Tp is not null.
2. `__not_null(Tp* __ptr);` Case for pointers to functions.
3. `__not_null(_Ret _Class::* __ptr);` Case for pointers to members.
4. `__not_null(function<Tp> const&);`: Cases for other std::functions.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11111
llvm-svn: 245335
When I was refactoring the unique_ptr.single.ctor tests I added a test
deleter, 'NCDeleter', to deleter.h. Other tests that include deleter.h
redefine the NCDeleter type causing test failures.
llvm-svn: 243733
One of the last sections of tests that still fail in C++03 are the unique_ptr
tests. This patch begins cleaning up the tests and fixing C++03 failures.
The main changes of this patch:
- The "Deleter" type in "deleter.h" tried to be "move-only" in C++03. However
the move simulation no longer works (see "__rv"). "Deleter" is now copy
constructible in C++03. However copying "Deleter" will "move" the test value
instead of copying it.
- Reduce the unique.ptr.single.ctor tests files from ~25 to 4. There is no
reason the tests were split through so many files.
llvm-svn: 243730
<__functional_03> provides the C++03 definitions for std::memfun and
std::function. However the interaction between <functional> and <__functional_03>
is ugly and duplicates code needlessly. This patch cleans up how the two
headers work together.
The major changes are:
- Provide placeholders, is_bind_expression and is_placeholder in <functional>
for both C++03 and C++11.
- Provide bad_function_call, function fwd decl,
__maybe_derive_from_unary_function and __maybe_derive_from_binary_function
in <functional> for both C++03 and C++11.
- Move the <__functional_03> include to the bottom of <functional>. This makes
it easier to see how <__functional_03> interacts with <functional>
- Remove a commented out implementation of bind in C++03. It's never going
to get implemented.
- Mark almost all std::bind tests as unsupported in C++03. std::is_placeholder
works in C++03 and C++11. std::is_bind_expression is provided in C++03 but
always returns false.
llvm-svn: 242870
Summary: This patch adds proper guards to the is_destructible tests depending on the standard version so that they pass in c++03.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10047
llvm-svn: 242612
Automatically enable clang verify whenever the '-verify-ignore-unexpected' flag
is supported.
Failure tests are run using verify if they contain one or more "expected-*"
diagnostics tags. Otherwise they are run normally.
llvm-svn: 241492
One of the aspects of CloudABI is that it aims to help you write code
that is thread-safe out of the box. This is very important if you want
to write libraries that are easy to reuse. For CloudABI we decided to
not provide the thread-unsafe functions. So far this is working out
pretty well, as thread-unsafety issues are detected really early on.
The following patch adds a knob to libc++,
_LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS, that can be set to disable
thread-unsafe functions that can easily be avoided in practice. The
following functions are not thread-safe:
- <clocale>: locale handles should be preferred over setlocale().
- <cstdlib>: mbrlen(), mbrtowc() and wcrtomb() should be preferred over
their non-restartable counterparts.
- <ctime>: asctime(), ctime(), gmtime() and localtime() are not
thread-safe. The first two are also deprecated by POSIX.
Differential Revision: http://reviews.llvm.org/D8703
Reviewed by: marshall
llvm-svn: 240527
The C++03 version of function tried to default construct the allocator
in the uses allocator constructors when no allocation was performed. These
constructors would fail to compile when used with allocators that had no
default constructor.
llvm-svn: 239708
The two main fixes this patch contains are:
- use __identity_t instead of common_type. common_type was used as an
identity metafunction but the decay resulted in incorrect results.
- Pointers to free functions were not counted as functions. Remove the pointer
before checking if a type is a function.
llvm-svn: 239668
This patch fixes LWG issue 2422 by removing the DECAY_COPY from call once.
The review can be found here: http://reviews.llvm.org/D10191
llvm-svn: 239654
Replacing the dependancy on __member_function_traits with is_function allows
is_member_function_pointer to work more often. In particular it allows it to
work when we don't have variadic templates but the function has an arity > 3.
llvm-svn: 239649
Within the shared state methods do not unlock the lock guards manually. This
could cause a race condition where the shared state is destroyed before the
method is complete.
llvm-svn: 239577
Marshall Clow