| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 283996
|
|
|
|
| |
llvm-svn: 283994
|
|
|
|
| |
llvm-svn: 283993
|
|
|
|
| |
llvm-svn: 283991
|
|
|
|
| |
llvm-svn: 283983
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adapt implementation of Library Fundamentals TS optional into an implementation of N4606 optional.
- Update relational operators per http://wg21.link/P0307
- Update to requirements of http://wg21.link/P0032
- Extension: Implement trivial copy/move construction/assignment for `optional<T>` when `T` is trivially copyable.
Audit P/Rs for optional LWG issues:
- 2756 "C++ WP optional<T> should 'forward' T's implicit conversions" Implemented, which also resolves 2753 "Optional's constructors and assignments need constraints" (modulo my refusal to explicitly delete the move operations, which is a design error that I'm working on correcting in the 2756 P/R).
- 2736 "nullopt_t insufficiently constrained" Already conforming. I've added a test ensuring that `nullopt_t` is not copy-initializable from an empty braced-init-list, which I believe is the root intent of the issue, to avoid regression.
- 2740 "constexpr optional<T>::operator->" Already conforming.
- 2746 "Inconsistency between requirements for emplace between optional and variant" No P/R, but note that the author's '"suggested resolution" is already implemented.
- 2748 "swappable traits for optionals" Already conforming.
- 2753 "Optional's constructors and assignments need constraints" Implemented.
Most of the work for this patch was done by Casey Carter @ Microsoft. Thank you Casey!
Reviewers: mclow.lists, CaseyCarter, EricWF
Differential Revision: https://reviews.llvm.org/D22741
llvm-svn: 283980
|
|
|
|
| |
llvm-svn: 283978
|
|
|
|
|
|
|
|
| |
This patch is largely thanks to Casey Carter @ Microsoft. He did the initial
work of porting our experimental implementation and tests over to namespace
std.
llvm-svn: 283977
|
|
|
|
| |
llvm-svn: 283976
|
|
|
|
| |
llvm-svn: 283975
|
|
|
|
| |
llvm-svn: 283960
|
|
|
|
| |
llvm-svn: 283958
|
|
|
|
|
|
| |
error_code
llvm-svn: 283951
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
FreeBSD ships an old ABI for std::pair which requires that it have non-trivial copy/move constructors. Currently the non-trivial copy/move is achieved by providing explicit definitions of the constructors. This is problematic because it means the constructors don't SFINAE properly. In order to SFINAE copy/move constructors they have to be explicitly defaulted and hense non-trivial.
This patch attempts to provide SFINAE'ing copy/move constructors for std::pair while still making them non-trivial. It does this by adding a base class with a non-trivial copy constructor and then allowing pair's constructors to be generated by the compiler. This also allows the constructors to be constexpr.
Reviewers: emaste, theraven, rsmith, dim
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25389
llvm-svn: 283944
|
|
|
|
| |
llvm-svn: 283941
|
|
|
|
|
|
| |
is LWG#2062, but we already do this. No changes to the library, just adding tests.
llvm-svn: 283780
|
|
|
|
|
|
| |
sure that we keep doing it.
llvm-svn: 283749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__builtin_addressof was added to the GCC trunk in the past week. This patch
teaches libc++ about it so it can correctly provide constexpr addressof.
Unfortunately this patch will break users of earlier GCC 7 builds, since
we expect __builtin_addressof but one won't be provided. One option would be
to only use __builtin_addressof for GCC 7.1 and above, but that means
waiting for another release.
Instead I've specifically chosen to break older GCC 7 versions. Since GCC 7
has yet to be released, and the 7.0 release is a development release, I
believe that anybody currently using GCC 7.0 will have no issue upgrading.
llvm-svn: 283715
|
|
|
|
| |
llvm-svn: 283700
|
|
|
|
| |
llvm-svn: 283644
|
|
|
|
| |
llvm-svn: 283643
|
|
|
|
| |
llvm-svn: 283633
|
|
|
|
| |
llvm-svn: 283632
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
To quote STL the problems with stack allocator are"
>"stack_allocator<T, N> is seriously nonconformant to N4582 17.6.3.5 [allocator.requirements].
> First, it lacks a rebinding constructor. (The nested "struct rebind" isn't sufficient.)
> Second, it lacks templated equality/inequality.
> Third, it completely ignores alignment.
> Finally, and most severely, the Standard forbids its existence. Allocators are forbidden from returning memory "inside themselves". This requirement is implied by the Standard's requirements for rebinding and equality. It's permitted to return memory from a separate buffer object on the stack, though."
This patch attempts to address all of those issues.
First, instead of storing the buffer inside the allocator I've change `stack_allocator` to accept the buffer as an argument.
Second, in order to fix rebinding I changed the parameter list from `<class T, size_t NumElements>` to `<class T, size_t NumBytes>`. This allows allocator rebinding
between types that have different sizes.
Third, I added copy and rebinding constructors and assignment operators.
And finally I fixed the allocation logic to always return properly aligned storage.
Reviewers: mclow.lists, howard.hinnant, STL_MSFT
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25154
llvm-svn: 283631
|
|
|
|
| |
llvm-svn: 283618
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix self-swap. Patch from Casey Carter.
* Remove workarounds and tests for types with deleted move constructors. This
was originally added as part of a LWG proposed resolution that has since
changed.
* Re-apply most recent PR for LWG 2769.
* Re-apply most recent PR for LWG 2754. Specifically fix the SFINAE checks to
use the decayed type.
* Fix tests to allow moved-from std::any's to have a non-empty state. This is
the behavior of MSVC's std::any.
* Various whitespace and test fixes.
llvm-svn: 283606
|
|
|
|
| |
llvm-svn: 283580
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First batch of changes to get some of these XFAILs working in the
no-exceptions libc++ variant.
Changed some XFAILs to UNSUPPORTED where the test is all about exception
handling. In other cases, used the test macros TEST_THROW and
TEST_HAS_NO_EXCEPTIONS to conditionally exclude those parts of the test
that concerns exception handling behaviour.
Reviewers: EricWF, mclow.lists
Differential revision: https://reviews.llvm.org/D24562
llvm-svn: 283441
|
|
|
|
| |
llvm-svn: 283360
|
|
|
|
| |
llvm-svn: 283339
|
|
|
|
| |
llvm-svn: 283331
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: There's a macro scheme already being used for __has_feature etc. Use it for __has_include too, which makes MSVC happy (it doesn't support __has_include yet, and unguarded use explodes horribly).
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25251
llvm-svn: 283260
|
|
|
|
|
|
| |
checked 'unqualified void'. This was brought up by LWG#2738
llvm-svn: 283161
|
|
|
|
|
|
|
| |
This commit splits the file extensions before determining the test
format. This allows libc++abi to add assembly-based test cases.
llvm-svn: 283118
|
|
|
|
| |
llvm-svn: 283032
|
|
|
|
| |
llvm-svn: 283030
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`std::move` and `std::forward` were not marked constexpr in C++11. This can be very damaging because it makes otherwise constant expressions non-constant. For example:
```
#include <utility>
template <class T>
struct Foo {
constexpr Foo(T&& tx) : t(std::move(tx)) {}
T t;
};
[[clang::require_constant_initialization]] Foo<int> f(42); // Foo should be constant initialized but C++11 move is not constexpr. As a result `f` is an unsafe global.
```
This patch applies `constexpr` to `move` and `forward` as an extension in C++11. Normally the library is not allowed to add `constexpr` because it may be observable to the user. In particular adding constexpr may cause valid code to stop compiling. However these problems only happen in more complex situations, like making `__invoke(...)` constexpr. `forward` and `move` are simply enough that applying `constexpr` is safe.
Note that libstdc++ has offered this extension since at least 4.8.1.
Most of the changes in this patch are simply test cleanups or additions. The main changes in the tests are:
* Fold all `forward_N.fail.cpp` tests into a single `forward.fail.cpp` test using -verify.
* Delete most `move_only_N.fail.cpp` tests because they weren't actually testing anything.
* Fold `move_copy.pass.cpp` and `move_only.pass.cpp` into a single `move.pass.cpp` test.
* Add return type and noexcept tests for `forward` and `move`.
Reviewers: rsmith, mclow.lists, EricWF
Subscribers: K-ballo, loladiro
Differential Revision: https://reviews.llvm.org/D24637
llvm-svn: 282439
|
|
|
|
| |
llvm-svn: 282352
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Libc++ still uses per-feature configuration macros when configuring for C++11. However libc++ requires a feature-complete C++11 compiler so there is no reason to check individual features. This patch starts the process of removing the feature specific macros and replacing their usage with `_LIBCPP_CXX03_LANG`.
This patch removes the __config macros:
* _LIBCPP_HAS_NO_TRAILING_RETURN
* _LIBCPP_HAS_NO_TEMPLATE_ALIASES
* _LIBCPP_HAS_NO_ADVANCED_SFINAE
* _LIBCPP_HAS_NO_DEFAULT_FUNCTION_TEMPLATE_ARGS
* _LIBCPP_HAS_NO_STATIC_ASSERT
As a drive I also changed our C++03 static_assert to use _Static_assert if available.
I plan to commit this without review if nobody voices an objection.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24895
llvm-svn: 282347
|
|
|
|
| |
llvm-svn: 282343
|
|
|
|
|
|
| |
would wait for these to be voted upon at a committee meeting (November), but the current draft standard is broken, and this should fix it. (And if it doesn't, we want to know about it soonest)
llvm-svn: 282342
|
|
|
|
| |
llvm-svn: 282332
|
|
|
|
|
|
| |
tests for is_error_code and is_error_condition, since they were really lacking. Thanks to Alisdair for the heads-up that we were missing these.
llvm-svn: 282331
|
|
|
|
| |
llvm-svn: 282134
|
|
|
|
|
|
| |
uses_allocator_v
llvm-svn: 282126
|
|
|
|
|
|
| |
This is the only test failing in c++98 mode at the moment.
llvm-svn: 281731
|
|
|
|
|
|
|
|
| |
Allow building with LLVM_USE_SANITIZER=“Address;Undefined” (and “Undefined;Address”).
Differential Revision: https://reviews.llvm.org/D24569
llvm-svn: 281603
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24297
llvm-svn: 281477
|
|
|
|
|
|
|
|
| |
tests on Darwin with sanitizers
Differential Revision: https://reviews.llvm.org/D24297
llvm-svn: 281476
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
|