| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 252407
|
|
|
|
| |
llvm-svn: 252406
|
|
|
|
| |
llvm-svn: 252195
|
|
|
|
|
|
| |
unitialized_copy tests
llvm-svn: 251804
|
|
|
|
|
|
| |
heads-up.
llvm-svn: 251802
|
|
|
|
| |
llvm-svn: 251767
|
|
|
|
|
|
| |
for C++17. Significantly augment the existing tests.
llvm-svn: 251766
|
|
|
|
| |
llvm-svn: 251618
|
|
|
|
| |
llvm-svn: 251257
|
|
|
|
| |
llvm-svn: 251254
|
|
|
|
|
|
| |
incorrect
llvm-svn: 251252
|
|
|
|
| |
llvm-svn: 251250
|
|
|
|
| |
llvm-svn: 251247
|
|
|
|
| |
llvm-svn: 251246
|
|
|
|
|
|
|
| |
On a system with LC_COLLATE=C, this takes precedence over a non-C LANG
the test tries to impose and the test fails.
llvm-svn: 251131
|
|
|
|
|
|
| |
Previously, this resulted in us declaring a template for static_assert emulation within the 'extern "C"' context, which is ill-formed.
llvm-svn: 250247
|
|
|
|
|
|
| |
C++03 mode.
llvm-svn: 249938
|
|
|
|
| |
llvm-svn: 249936
|
|
|
|
|
|
| |
doesn't provide a correct overload set for some functions.
llvm-svn: 249932
|
|
|
|
|
|
| |
and std::, and that the names in :: and std:: are declaring the same entity.
llvm-svn: 249931
|
|
|
|
| |
llvm-svn: 249926
|
|
|
|
| |
llvm-svn: 249889
|
|
|
|
| |
llvm-svn: 249800
|
|
|
|
|
|
| |
As with <stddef.h>, skip our custom header if __need_FILE or __need___FILE is defined.
llvm-svn: 249798
|
|
|
|
| |
llvm-svn: 249780
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are a bunch of macros (__need_size_t etc) that request just one piece of
<stddef.h>; if any one of these is defined, we just directly include the
underlying header.
Note that <stddef.h> provides a ::nullptr_t. We don't want that available to
includers of <cstddef>, so instead of following the usual pattern where <cfoo>
includes <foo.h> then pulls things from :: into std:: with using-declarations,
we implement <stddef.h> and <cstddef> separately; both include <__nullptr> for
the definition of std::nullptr_t.
llvm-svn: 249761
|
|
|
|
| |
llvm-svn: 249743
|
|
|
|
| |
llvm-svn: 249742
|
|
|
|
| |
llvm-svn: 249741
|
|
|
|
| |
llvm-svn: 249738
|
|
|
|
|
|
| |
being cleared. Now we are
llvm-svn: 249593
|
|
|
|
| |
llvm-svn: 249349
|
|
|
|
|
|
| |
generated pages
llvm-svn: 249325
|
|
|
|
|
|
| |
tolerances
llvm-svn: 248993
|
|
|
|
| |
llvm-svn: 248989
|
|
|
|
| |
llvm-svn: 248987
|
|
|
|
|
|
| |
the fix, but for the wrong reason. Now it fails for the right reason.
llvm-svn: 248307
|
|
|
|
| |
llvm-svn: 248305
|
|
|
|
|
|
| |
deprecated doesn't change the fact that we have to test it.
llvm-svn: 247704
|
|
|
|
|
|
| |
which does the same thing, w/o having clang and gcc warn with -Wall.
llvm-svn: 247695
|
|
|
|
| |
llvm-svn: 247036
|
|
|
|
|
|
|
| |
This patch also fixes PR22135. (https://llvm.org/bugs/show_bug.cgi?id=22135)
See the review for more information: http://reviews.llvm.org/D6964
llvm-svn: 246977
|
|
|
|
| |
llvm-svn: 246399
|
|
|
|
| |
llvm-svn: 246392
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 246273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 246055
|
|
|
|
| |
llvm-svn: 246022
|