| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
I have a big patch coming up, and this indirection is required to avoid hitting the following after my big change:
error: empty struct has size 0 in C, size 1 in C++ [-Werror,-Wextern-c-compat]
llvm-svn: 350772
|
|
|
|
|
|
| |
There were 3 tests with 'int main(void)', and 6 with the return type on a different line. I'm about to send a patch for main in tests, and this NFC change is unrelated.
llvm-svn: 350770
|
|
|
|
| |
llvm-svn: 350739
|
|
|
|
|
|
| |
AppleClang 10 has been fixed and so these tests don't fail anymore.
llvm-svn: 350736
|
|
|
|
| |
llvm-svn: 350692
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r306722 added diagnostics when aligned allocation is used with deployment
targets that do not support it, but the first macosx supporting aligned
allocation was incorrectly set to 10.13. In reality, the dylib shipped
with macosx10.13 does not support aligned allocation, but the dylib
shipped with macosx10.14 does.
Reviewers: ahatanak
Subscribers: christof, jkorous, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D56445
llvm-svn: 350649
|
|
|
|
|
|
| |
This 'fixes' PR#38052 - std::fstream still good after closing and updating content.
llvm-svn: 350603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
range with const-ness mismatch.
We already have a specialization that will use memcpy for construction
of trivial types from an iterator range like
std::vector<int>(int *, int *);
But if we have const-ness mismatch like
std::vector<int>(const int *, const int *);
we would use a slow path that copies each element individually. This change
enables the optimal specialization for const-ness mismatch. Fixes PR37574.
Contributions to the patch are made by Arthur O'Dwyer, Louis Dionne.
rdar://problem/40485845
Reviewers: mclow.lists, EricWF, ldionne, scanon
Reviewed By: ldionne
Subscribers: christof, ldionne, howard.hinnant, cfe-commits
Differential Revision: https://reviews.llvm.org/D48342
llvm-svn: 350583
|
|
|
|
| |
llvm-svn: 350550
|
|
|
|
|
|
| |
the appropriate tests. No actual tests yet, so NFC.
llvm-svn: 350535
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes <experimental/foo> to use #warning instead of
is harmful to common feature detection idioms.
We should also consider only emitting the warning when __DEPRECATED is
defined, like we do in the <ext/foo> headers. Users may want to specify
"-Werror=-W#warnings" while still ignoring the libc++ warnings.
llvm-svn: 350485
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
last_write_time(sym, new_time) changes the modification time of the file
referenced by the symlink. But reading through the symlink may change the
symlinks's access time.
This meant the previous test that checked that the symlinks access
time was unchanged was incorrect and made the test flaky.
This patch removes this test (there really is no non-flaky way
to test that the new access time coorisponds to the time at which
the symlink was last dereferenced). This should unflake the test.
llvm-svn: 350478
|
|
|
|
| |
llvm-svn: 350330
|
|
|
|
| |
llvm-svn: 349888
|
|
|
|
| |
llvm-svn: 349886
|
|
|
|
|
|
| |
path("/dir/").lexically_relative("/dir"); now returns "." instead of ""
llvm-svn: 349885
|
|
|
|
|
|
|
|
|
| |
This prevents things like:
using namespace std::filesystem;
auto x = L"a/b" == std::string("a/b");
llvm-svn: 349884
|
|
|
|
|
|
|
| |
This patch adds std::chrono::file_clock, but without breaking the
existing ABI for std::filesystem.
llvm-svn: 349883
|
|
|
|
|
|
|
|
|
| |
This patch implements path::compare according to the current spec. The
only observable change is the ordering of "/foo" and "foo", which orders
the two paths based on having or not having a root directory (instead
of lexically comparing "/" to "foo").
llvm-svn: 349881
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some tests assume that iteration through an unordered multimap elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch introduces checks verifying that any iteration will return elements
exactly from a set of valid values and without repetition, but in no
particular order.
Reviewed as https://reviews.llvm.org/D54838.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 349780
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Makes libc++ behavior consistent between C++03 and C++11.
Can use `decltype` in C++03 because `include/__config` defines a macro when
`decltype` is not available.
Reviewers: mclow.lists, EricWF, erik.pilkington, ldionne
Reviewed By: ldionne
Subscribers: dexonsmith, cfe-commits, howard.hinnant, ldionne, christof, jkorous, Quuxplusone
Differential Revision: https://reviews.llvm.org/D48753
llvm-svn: 349676
|
|
|
|
| |
llvm-svn: 349663
|
|
|
|
| |
llvm-svn: 349639
|
|
|
|
|
|
| |
https://reviews.llvm.org/D55777. Thanks to Andrey Maksimov for the patch.
llvm-svn: 349566
|
|
|
|
|
|
| |
cwchar.pass.cpp to avoid constructing a couple things from zero - since apparently they can be enums in some weird C library. NFC there, either, since the values were never used.
llvm-svn: 349522
|
|
|
|
|
|
|
| |
That test doesn't fail anymore since r349378, since the assertions that
r349378 removed must have been bugs in the dylib at some point.
llvm-svn: 349484
|
|
|
|
|
|
| |
I forgot that those don't behave like Clang trunk, again.
llvm-svn: 349427
|
|
|
|
|
|
|
|
|
| |
This test was initially marked as XFAIL using `XFAIL: macosx10.YY`, and
was then moved to `UNSUPPORTED: macosx10.YY`. The intent is to mark the
test as XFAILing when a deployment target older than macosx10.14 is used,
and the right way to do this is `XFAIL: availability=macosx10.YY`.
llvm-svn: 349426
|
|
|
|
| |
llvm-svn: 349387
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a target_info definition for NetBSD. The definition is based
on the one used by FreeBSD, with libcxxrt replaced by libc++abi,
and using llvm-libunwind since we need to use its unwinder
implementation to build anyway.
Additionally, XFAIL the 30 tests that fail because of non-implemented
locale features. According to the manual, NetBSD implements only
LC_CTYPE part of locale handling. However, there is a locale database
in the system and locale specifications are validated against it,
so it makes sense to list the common locales as supported.
If I'm counting correctly, this change enables additional 43 passing
tests.
Differential Revision: https://reviews.llvm.org/D55767
llvm-svn: 349379
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the two test cases for \xDA and \xFA with UTF-8 locale, as both
characters alone are invalid in UTF-8 (short sequences). Upon removing
them, the test passes on Linux again (and also on NetBSD, after adding
appropriate locale configuration).
Differential Revision: https://reviews.llvm.org/D55746
llvm-svn: 349378
|
|
|
|
| |
llvm-svn: 349373
|
|
|
|
| |
llvm-svn: 349364
|
|
|
|
|
|
|
|
|
|
| |
This is a re-application of r345525, which had been reverted by fear of
a regression.
Reviewed as https://reviews.llvm.org/D53994.
Thanks to Denis Yaroshevskiy for the patch.
llvm-svn: 349358
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 349305
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 349294
|
|
|
|
| |
llvm-svn: 349252
|
|
|
|
| |
llvm-svn: 349189
|
|
|
|
| |
llvm-svn: 349187
|
|
|
|
|
|
| |
Fundamentals 2 for C++20. Reviewed as https://reviews.llvm.org/D55532
llvm-svn: 349178
|
|
|
|
| |
llvm-svn: 349071
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 348994
|
|
|
|
| |
llvm-svn: 348973
|
|
|
|
| |
llvm-svn: 348968
|
|
|
|
|
|
|
| |
NetBSD also uses tv_sec==-1 as error status indicator, and does not
support setting such a value.
llvm-svn: 348967
|
|
|
|
| |
llvm-svn: 348872
|
|
|
|
|
|
|
| |
GCC 4.9 seems to think that a constexpr default constructor implies
the constructor to be noexcept.
llvm-svn: 348850
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 348847
|
|
|
|
| |
llvm-svn: 348846
|
|
|
|
| |
llvm-svn: 348829
|