Summary:
This patch implements the library side of P0035R4. The implementation is thanks to @rsmith.
In addition to the C++17 implementation, the library implementation can be explicitly turned on using `-faligned-allocation` in all dialects.
Reviewers: mclow.lists, rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D25591
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@284206 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
On FreeBSD, for ABI compatibility reasons, the pair trivial copy
constructor is disabled, using the aptly-named
`_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR` define.
Disable the related tests when this define is on, so they don't fail
unexpectedly.
Reviewers: emaste, rsmith, theraven, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25449
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@284047 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@283980 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@283977 91177308-0d34-0410-b5e6-96231b3b80d8
__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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@283715 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@283631 91177308-0d34-0410-b5e6-96231b3b80d8
* 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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@283606 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@283441 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@282439 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@282347 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes PR30260 by using a (void*) cast on the placement argument
to placement new to casts away the const. See also http://llvm.org/PR30260.
As a drive by change this patch also changes the header guard for
<experimental/optional> to _LIBCPP_EXPERIMENTAL_OPTIONAL from _LIBCPP_OPTIONAL.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@280775 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch allows threads not created using `std::thread` to use `std::notify_all_at_thread_exit` by ensuring the TL state has been initialized within `std::notify_all_at_thread_exit`.
Additionally this patch "fixes" a potential oddity in `__thread_local_pointer::reset(pointer)`, which would previously delete the old thread local data. However there should *never* be old thread local data because pthread *should* null it out on thread exit. Unfortunately it's possible that pthread failed to do this according to the spec:
>
> Upon key creation, the value NULL shall be associated with the new key in all active threads. Upon thread creation, the value NULL shall be associated with all defined keys in the new thread.
>
> An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.
>
> If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, implementations may stop calling destructors, or they may continue calling destructors until no non-NULL values with associated destructors exist, even though this might result in an infinite loop.
However if pthread fails to delete the value it is probably incorrect for us to do it. Destroying the value performs all of the "at thread exit" actions registered with it but we are way past "at thread exit".
Reviewers: mclow.lists, bcraig, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24159
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@280588 91177308-0d34-0410-b5e6-96231b3b80d8
