That macro has been defined to _LIBCPP_HIDE_FROM_ABI_AFTER_V1 for many
weeks now, so we're actually replacing uses of it for uses of
_LIBCPP_HIDE_FROM_ABI_AFTER_V1 directly.
This should not change or break anything since the two macros are
100% equivalent, unless somebody is (incorrectly!) relying on
_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY being defined.
llvm-svn: 344641
Revert r344535 "Wrap up the new chrono literals in an #ifdef..."
Revert r344546 "Mark a couple of test cases as 'C++17-only'..."
Some of the buildbot failures were masked by another error,
and this one was probably missed.
llvm-svn: 344580
libc++ has dropped support for Mac OS 10.6 for a while, and we don't
have any testers set up for that OS.
This commit puts in an error message so that people can reach out to
the libc++ maintainers in case support for 10.6 is still expected (as
opposed to silently failing in weird ways). We can completely drop
support for 10.6 and remove the error message some time in the future
when we're sure that nobody is relying on it.
llvm-svn: 344576
Summary:
Benchmarks for construct, copy, move, swap, destroy and invoke, with 8
different input states.
For the cases that matter, it tests with and without allowing constant
value propagation from construction into the operation tested.
This also adds helper functions to generate the cartesian product of
different configurations and generate benchmarks for all of them.
Reviewers: EricWF
Subscribers: christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53087
llvm-svn: 344415
There are two cases:
1. The library has all it needs to provide align_val_t and the
new/delete overloads needed to support aligned allocation.
2. The compiler has actually turned the language feature on.
There are times where libc++ needs to distinguish between the two.
This patch adds the additional macro
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1)
does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the
compiler has not enabled the language feature.
Additionally this patch cleans up a number of other macros related
to detection of aligned allocation machinery.
llvm-svn: 344207
While __cplusplus was only used a few dozen times, TEST_STD_VAR is used
more than 2000 times. So we replace the former by the latter for
consistency in the tests. There should be no functional change.
llvm-svn: 344194
Summary:
Scoped capabilities need to be annotated as such, otherwise the thread
safety analysis won't work as intended.
Fixes PR39234.
Reviewers: ldionne
Reviewed By: ldionne
Subscribers: christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53049
llvm-svn: 344096
PR38682 added a test to check for a race condition in std::future.
Part of the fix is part of the dylib, but there is no released version
of mac OS X that ships a dylib containing the fix. Hence, this test can
(and sometimes does) when testing on OS X. This commit marks the test
as unsupported to avoid spurious failures.
llvm-svn: 344053
This avoids duplicate directories when the filename includes path.
Fixes PR39145
Differential Revision: https://reviews.llvm.org/D52762
llvm-svn: 343753
Summary:
Add error messages to a couple of static_asserts in span to match the
style used in the rest of the file. Also fix an extra paren typo in a
assert error message.
Committed on behalf of Jason Lovett.
Reviewers: ldionne
Subscribers: libcxx-commits
Differential Revision: https://reviews.llvm.org/D52841
llvm-svn: 343725
Summary:
C89 4.10.3.2 The free function
C99 7.20.3.2 The free function
C11 7.22.3.3 The free function
If ptr is a null pointer, no action shall occur.
_aligned_free on MSDN:
If memblock is a NULL pointer, this function simply performs no actions.
Reviewers: EricWF, mclow.lists, khng300, hotpxl
Reviewed By: mclow.lists, khng300, hotpxl
Subscribers: lichray, llvm-commits, hotpxl, khng300, christof, ldionne, cfe-commits, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52401
llvm-svn: 343503
When we're using clang-cl and Microsoft's runtime implementation,
we don't provide align_val_t or aligned new/delete ourselves.
This patch updates the _LIBCPP_HAS_NO_ALIGNED_ALLOCATION macro
to reflect this.
llvm-svn: 343441
Although libc++ doesn't yet support Windows we still have Windows
builders to track our progress.
Currently the clang-cl configuration seems broken because it doesn't
support -std=c++11 and instead requires /std:c++11. This patch attempts
to fix this.
llvm-svn: 343431
Summary:
The ABI version used by libc++ is a configuration option just like any other
configuration option. It is a knob that can be used by vendors to customize
the libc++ that they ship. As such, we should not be hardcoding vendor-specific
configuration choices in libc++.
When building libc++ for Fuchsia, Fuchsia's build scripts should simply define
the libc++ ABI version to 2 -- this will result in the _LIBCPP_ABI_VERSION
macro being defined in the __config header that is generated when libc++ is
built and installed, which is the correct way to customize libc++'s behavior
for specific vendors.
Reviewers: phosek, EricWF
Subscribers: mgorny, christof, dexonsmith, cfe-commits, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52397
llvm-svn: 343079
A review for the change was opened in https://reviews.llvm.org/D52401
but the change was committed before being approved by any of the code
owners for libc++.
llvm-svn: 342938
C89 4.10.3.2 The free function
C99 7.20.3.2 The free function
C11 7.22.3.3 The free function
If ptr is a null pointer, no action shall occur.
_aligned_free on MSDN:
If memblock is a NULL pointer, this function simply performs no actions.
Reviewers: EricWF, mclow.lists
Subscribers: christof, ldionne, cfe-commits, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52401
llvm-svn: 342936
Debian build bots are running Clang 4, which apparently does not support
the "deprecated" attribute properly. Clang pretends to support the attribute,
but the attribute doesn't do anything.
(live example: https://wandbox.org/permlink/0De69aXns0t1D59r)
On a separate note, I'm not sure I understand why we're even running the
libc++ tests under Clang-4. Is this a configuration we support? I can
understand that libc++ should _build_ with Clang 4, but it's not clear
to me that new libc++ headers should be usable under older compilers
like that.
llvm-svn: 342854
Louis Dionne