Replace the mknod() call with socket() + bind() for creating unix
sockets. The mknod() method is not portable and does not work
on NetBSD while binding the socket should work on all systems supporting
unix sockets.
Differential Revision: https://reviews.llvm.org/D55576
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@349305 91177308-0d34-0410-b5e6-96231b3b80d8
Explicitly disable the -Wformat-zero-length diagnostic when running
ctime tests, since one of the test cases passes zero-length format
string to strftime(). When strftime() is appropriately decorated
with __attribute__(format, ...), this caused the test to fail because
of this warning (e.g. on NetBSD).
Differential Revision: https://reviews.llvm.org/D55661
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@349294 91177308-0d34-0410-b5e6-96231b3b80d8
Also, add tests making sure that vector and deque both catch the problem
when assertions are enabled. Otherwise, deque would segfault and vector
would never terminate.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348994 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
std::tuple marks its constructors as noexcept when the corresponding
memberwise constructors are noexcept too -- this commit improves std::pair
so that it behaves the same.
This is a re-application of r348824, which broke the build in C++03 mode
because a test was marked as supported in C++03 when it shouldn't be.
Note:
I did not add support in the explicit and non-explicit `pair(_Tuple&& __p)`
constructors because those are non-standard extensions, and supporting them
properly is tedious (we have to copy the rvalue-referenceness of the deduced
_Tuple&& onto the result of tuple_element).
<rdar://problem/29537079>
Reviewers: mclow.lists, EricWF
Subscribers: christof, llvm-commits
Differential Revision: https://reviews.llvm.org/D48669
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348847 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
std::tuple marks its constructors as noexcept when the corresponding
memberwise constructors are noexcept too -- this commit improves std::pair
so that it behaves the same.
Note:
I did not add support in the explicit and non-explicit `pair(_Tuple&& __p)`
constructors because those are non-standard extensions, and supporting them
properly is tedious (we have to copy the rvalue-referenceness of the deduced
_Tuple&& onto the result of tuple_element).
<rdar://problem/29537079>
Reviewers: mclow.lists, EricWF
Subscribers: christof, llvm-commits
Differential Revision: https://reviews.llvm.org/D48669
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348824 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When providing a non-const-callable comparator in a map or set, the
warning diagnostic does not include the point of instantiation of
the container that triggered the warning, which makes it difficult
to track down the problem. This commit improves the diagnostic by
placing it directly in the body of the associative container.
The same change is applied to unordered associative containers, which
had a similar problem.
Finally, this commit cleans up the forward declarations of several
map and unordered_map helpers, which are not needed anymore.
<rdar://problem/41370747>
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48955
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348529 91177308-0d34-0410-b5e6-96231b3b80d8
The tests were marked to fail based on the 'availability' LIT feature.
However, those tests should really only be failing when we run them
against the dylibs that were deployed on macosx10.7 and macosx10.8,
which the deployment target has nothing to do with.
This caused the tests to unexpectedly pass when running the tests
with deployment target macosx10.{7,8} but running with a recent dylib.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348520 91177308-0d34-0410-b5e6-96231b3b80d8
The standard section [array.zero] requires the return value of begin()
and end() methods of a zero-sized array to be unique. Eric Fiselier
clarifies: "That unique value cannot be null, and must be properly aligned".
This patch adds checks for the first part of this clarification: unique
value returned by these methods cannot be null.
Reviewed as https://reviews.llvm.org/D55366.
Thanks to Andrey Maksimov for the patch.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348509 91177308-0d34-0410-b5e6-96231b3b80d8
The section array.zero says: "The return value of data() is unspecified".
This patch marks all checks of the array<T, 0>.data() return value as
libc++ specific.
Reviewed as https://reviews.llvm.org/D55364.
Thanks to Andrey Maksimov for the patch.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348485 91177308-0d34-0410-b5e6-96231b3b80d8
Whether an explicit instantiation declaration should be provided is not
a matter of availability markup.
This problem is exemplified by the fact that some tests were incorrectly
marked as XFAIL when they should instead have been using the definition
of streams from the headers, and hence passing, and that, regardless of
whether visibility annotations are enabled.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348436 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This was voted into C++20 in San Diego. Note that there was a revision
D0318R2 which did include unwrap_reference_t, but we mistakingly voted
P0318R1 into the C++20 Working Draft (which does not include
unwrap_reference_t). This patch implements D0318R2, which is what
we'll end up with in the Working Draft once this mistake has been
fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54485
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@348138 91177308-0d34-0410-b5e6-96231b3b80d8
The test was previously marked as unsupported on all Apple platforms, when
we really just want to mark it as unsupported for previously shipped dylibs
on macosx.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347920 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
std::bad_array_length was added by n3467, but this never made it into C++.
This commit removes the definition of std::bad_array_length from the headers
AND from the shared library. See the comments in the ABI changelog for details
about the ABI implications of this change.
Reviewers: mclow.lists, dexonsmith, howard.hinnant, EricWF
Subscribers: christof, jkorous, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54804
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347903 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 087f065cb0.
The tests were failing on 32 bit builds, and I don't have time
to clean them up right now. I'll recommit tomorrow with fixed tests.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347816 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713
This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.
This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.
I think we should commit this change immediately, and decide what we want to do about the ABI afterwards.
Reviewers: ldionne, EricWF
Reviewed By: EricWF
Subscribers: christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347787 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
std::dynarray had been proposed for C++14, but it was pulled out from C++14
and there are no plans to standardize it anymore.
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54801
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347783 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds an implementation of __resize_default_init as
described in P1072R2. Additionally, it uses it in filesystem to
demonstrate its intended utility.
Once P1072 lands, or if it changes it's interface, I will adjust
the internal libc++ implementation to match.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347589 91177308-0d34-0410-b5e6-96231b3b80d8
In r339743, I marked several aligned allocation tests as downright
unsupported on macosx in an attempt to unbreak the build. It turns
out that marking them as unuspported whenever we're on OS X is way
too coarse grained. This commit marks the tests as XFAIL with more
granularity.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347585 91177308-0d34-0410-b5e6-96231b3b80d8
The test was marked as failing whenever the deployment target was 10.12
or older, but in reality the test passes when the deployment target is
10.12 on recent Clangs. This happens because only older clangs do not
honor the -faligned-allocation flag, which disables any availability
error related to aligned allocation support, regardless of the
deployment target.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347580 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In PR39232, we noticed that some variant tests started failing in C++2a mode
with recent Clangs, because the rules for literal types changed in C++2a. As
a result, a temporary fix was checked in (enabling the test only in C++17).
This commit is what I believe should be the long term fix: I removed the
tests that checked constexpr default-constructibility with a weird type
from the tests for index() and valueless_by_exception(), and instead I
added tests for those using an obviously literal type in the test for the
default constructor.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, arphaman, libcxx-commits, rsmith
Differential Revision: https://reviews.llvm.org/D54767
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@347568 91177308-0d34-0410-b5e6-96231b3b80d8
