Summary:
This is not guaranteed to work since the characters after '__has_include('
have special lexing rules that can't possibly be applied when
__has_include is generated by a macro. It also breaks the crash reproducers
generated by -frewrite-includes (see https://llvm.org/pr37990).
Reviewers: EricWF, rsmith, mclow.lists
Reviewed By: mclow.lists
Differential Revision: https://reviews.llvm.org/D49067
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@337824 91177308-0d34-0410-b5e6-96231b3b80d8
this patch adds the <compare> header and implements all of it
except for [comp.alg].
As I understand it, the header is needed by the compiler in
when implementing the semantics of operator<=>. For that reason
I feel it's important to land this header early, despite
all compilers lacking support.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@329460 91177308-0d34-0410-b5e6-96231b3b80d8
The new/delete tests, in particular those which test replacement
functions, often fail when the optimizer is enabled because the
calls to new/delete may be optimized away, regardless of their side-effects.
This patch converts the tests to use DoNotOptimize in order to prevent
the elision.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@328245 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes std::allocator, and more specifically, all users
of __libcpp_allocate and __libcpp_deallocate, to support over-aligned
types.
__libcpp_allocate/deallocate now take an alignment parameter, and when
the specified alignment is greater than that supported by malloc/new,
the aligned version of operator new is called (assuming it's available).
When aligned new isn't available, the old behavior has been kept, and the
alignment parameter is ignored.
This patch depends on recent changes to __builtin_operator_new/delete which
allow them to be used to call any regular new/delete operator. By using
__builtin_operator_new/delete when possible, the new/delete erasure optimization
is maintained.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@328180 91177308-0d34-0410-b5e6-96231b3b80d8
This change works around a couple of bugs:
1. EDG doesn't like explicit constexpr in a derived class. This program:
struct Base {};
struct Derived : Base {
constexpr Derived() = default;
};
triggers "error: defaulted default constructor cannot be constexpr."
2. C1XX with /Za has no idea which constructor needs to be valid for copy elision.
The change also conditionally disables parts of the msvc_stdlib_force_include.hpp header that conflict with external configuration when _LIBCXX_IN_DEVCRT is defined.
Differential Revision: https://reviews.llvm.org/D32778
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@302707 91177308-0d34-0410-b5e6-96231b3b80d8
For reference deleter types the const qualifier on the return type
of get_deleter() should be ignored, and a non-const deleter should
be returned.
This patch fixes a bug where "const deleter_type&" is incorrectly
formed.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@300121 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This is my attempt to work around the C1XX bug described to me by @BillyONeal.
Reviewers: BillyONeal, STL_MSFT, CaseyCarter
Reviewed By: BillyONeal
Subscribers: cfe-commits, BillyONeal
Differential Revision: https://reviews.llvm.org/D31260
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@298554 91177308-0d34-0410-b5e6-96231b3b80d8
When -pedantic-errors is specified `__has_extension(<feature>)` is always
false when it would otherwise be true. This causes C++03 <atomic> to break
along with other issues.
This patch avoids the above problem by using __is_identifier(...) instead since
it is not affected by -pedantic-errors. For example instead of checking for
__has_extension(c_atomics) we now check `!__is_identifier(_Atomic)`, which
is only true when _Atomic is not a keyword provided by the compiler.
This patch applies similar changes to the detection logic for __decltype and
__nullptr as well.
Note that it does not apply this change to the C++03
`static_assert` macro since -Wc11-extensions warnings generated by expanding
that macro will appear in user code, and will not be suppressed as part of a
system header.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291995 91177308-0d34-0410-b5e6-96231b3b80d8
test/support/test_macros.h
For convenience/greppability, add macros for libcxx-specific static_asserts about noexceptness.
(Moving the definitions of ASSERT_NOEXCEPT/ASSERT_NOT_NOEXCEPT isn't technically necessary
because they're macros, but I think it's better style to define stuff before using it.)
test/std/utilities/tuple/tuple.tuple/tuple.apply/apply.pass.cpp
There was a completely unused `TrackedCallable obj;`.
apply() isn't depicted with conditional noexcept in C++17.
test/std/utilities/tuple/tuple.tuple/tuple.apply/make_from_tuple.pass.cpp
Now that we have LIBCPP_ASSERT_NOEXCEPT, use it.
Fixes D27622.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@289264 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
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@283260 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the weak_type typedef in shared_ptr. It is available in
C++17 and newer.
This patch also updates the _LIBCPP_STD_VER and TEST_STD_VER macros to
have the value of 16, since 2016 is the current year.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@273839 91177308-0d34-0410-b5e6-96231b3b80d8
So the macros TEST_HAS_NO_EXCEPTIONS and TEST_HAS_NO_RTTI were always
getting defined because I spelt __cpp_exceptions and __cpp_rtti as
__cxx_exceptions and __cxx_rtti.
Tests incoming after this patch.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@273381 91177308-0d34-0410-b5e6-96231b3b80d8
Add the completed std::experimental::filesystem implementation and tests.
The implementation supports C++11 or newer.
The TS is built as part of 'libc++experimental.a'. Users of the TS need to
manually link this library. Building and testing the TS can be disabled using
the CMake option '-DLIBCXX_ENABLE_FILESYSTEM=OFF'.
Currently 'libc++experimental.a' is not installed by default. To turn on the
installation of the library use '-DLIBCXX_INSTALL_EXPERIMENTAL_LIBRARY=ON'.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@273034 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@245463 91177308-0d34-0410-b5e6-96231b3b80d8
