When built against the old libc++ version the test was causing linker error
Undefined symbols for architecture x86_64:
"std::experimental::fundamentals_v1::pmr::new_delete_resource()", referenced from:
void test_evil<WidgetV0, WidgetV0>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV1>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV2>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV3>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV0>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV1>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV2>() in construct_piecewise_pair_evil.pass.cpp.o
...
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@334431 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The filesystem test was confused about access versus write / modification time. The spec says:
file_time_type last_write_time(const path& p, error_code& ec) noexcept;
Returns: The time of last data modification of p, determined as if by the value of the POSIX stat structure member st_mtime obtained as if by POSIX stat(). The signature with argument ec returns file_time_type::min() if an error occurs.
The test was looking at st_atime, not st_mtime, when comparing the result from last_write_time. That was probably due to using a pair instead of naming things nicely or using types. I opted to rename things so it's clearer.
This used to cause test bot failures.
<rdar://problem/40648859>
Reviewers: EricWF, mclow.lists, aemerson
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47557
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333723 91177308-0d34-0410-b5e6-96231b3b80d8
Patch from Arthur O'Dwyer.
In the TS, `uses_allocator` construction for `pair` tried to use an allocator
type of `memory_resource*`, which is incorrect because `memory_resource*` is
not an allocator type. LWG 2969 fixed it to use `polymorphic_allocator` as the
allocator type instead.
https://wg21.link/lwg2969
(D47090 included this in `<memory_resource>`; at Eric's request, I've split
this out into its own patch applied to the existing
`<experimental/memory_resource>` instead.)
Reviewed as https://reviews.llvm.org/D47109
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333384 91177308-0d34-0410-b5e6-96231b3b80d8
There are 3 changes:
* Renamed genertor.pass.cpp to generator.pass.cpp
* Removed nothing_to_do.pass.cpp
* Mark GCC 4.9 as UNSUPPORTED for the test files that have negative
narrowing conversion SFINAE test (see GCC PR63723).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@330655 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The patch includes all declarations, and also implements the following features:
* ABI.
* narrowing-conversion related SFIANE, including simd<> ctors and (static_)simd_cast.
Reviewers: mclow.lists, EricWF
Subscribers: lichray, sanjoy, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D41148
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@330627 91177308-0d34-0410-b5e6-96231b3b80d8
The proximate tests depended on `/net` not being a valid path,
however, on OS X it is.
Correct the tests to handle this.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@329038 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements P0430R2, who's largest change is adding the path::format
enumeration for supporting path format conversions in path constructors.
However, since libc++'s filesystem only really supports POSIX like systems,
there are no real changes needed. This patch simply adds the format enum
and then ignores it when it's passed to constructors.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@329031 91177308-0d34-0410-b5e6-96231b3b80d8
This is a fairly large patch that implements all of the filesystem NB comments
and the relative paths changes (ex. adding weakly_canonical). These issues
and papers are all interrelated so their implementation couldn't be split up
nicely.
This patch upgrades <experimental/filesystem> to match the C++17 spec and not
the published experimental TS spec. Some of the changes in this patch are both
API and ABI breaking, however libc++ makes no guarantee about stability for
experimental implementations.
The major changes in this patch are:
* Implement NB comments for filesystem (P0492R2), including:
* Implement `perm_options` enum as part of NB comments, and update the
`permissions` function to match.
* Implement changes to `remove_filename` and `replace_filename`
* Implement changes to `path::stem()` and `path::extension()` which support
splitting examples like `.profile`.
* Change path iteration to return an empty path instead of '.' for trailing
separators.
* Change `operator/=` to handle absolute paths on the RHS.
* Change `absolute` to no longer accept a current path argument.
* Implement relative paths according to NB comments (P0219r1)
* Combine `path.cpp` and `operations.cpp` since some path functions require
access to the operations internals, and some fs operations require access
to the path parser.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@329028 91177308-0d34-0410-b5e6-96231b3b80d8
The NB comments for filesystem changed permissions and added
a new enum `perm_options` which control how the permissions
are applied.
This implements than NB resolution
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@328476 91177308-0d34-0410-b5e6-96231b3b80d8
As I move towards implementing std::filesystem, there is a need to
make the existing tests run against both the std and experimental versions.
Additionally, it's helpful to allow running the tests against other
implementations of filesystem.
This patch converts the test to easily target either. First, it
adds a filesystem_include.hpp header which is soley responsible
for selecting and including the correct implementation. Second,
it converts existing tests to use this header instead of including
filesystem directly.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@328475 91177308-0d34-0410-b5e6-96231b3b80d8
APFS minimum supported file write time is -2^63 nanoseconds, which doesn't go
as far as `file_time_type::min()` that is equal to -2^63 microseconds on macOS.
This change doesn't affect filesystems that support `file_time_type` range only
for in-memory file time representation but not for on-disk representation. Such
filesystems are considered as `SupportsMinTime`.
rdar://problem/35865151
Reviewers: EricWF, Hahnfeld
Subscribers: jkorous-apple, mclow.lists, cfe-commits, christof
Differential Revision: https://reviews.llvm.org/D42755
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@326383 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes the noexcept declaration from filesystem
operations which require creating temporary paths or
creating a directory iterator. Either of these operations
can throw.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@324192 91177308-0d34-0410-b5e6-96231b3b80d8
Because path can be constructed from a ton of different types, including string
and wide strings, this caused it's streaming operators to suck up all sorts
of silly types via silly conversions. For example:
using namespace std::experimental::filesystem::v1;
std::wstring w(L"wide");
std::cout << w; // converts to path.
This patch tentatively adopts the resolution to LWG2989 and fixes the issue
by making the streaming operators friends of path.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@324189 91177308-0d34-0410-b5e6-96231b3b80d8
LWG 3013 points out that the constructors and increment members
of the directory iterators need to allocate, and therefore cannot
be marked noexcept.
It also points out that `is_empty` and `copy` likely need to allocate
as well, and as such can also not be noexcept.
This patch speculatively implements the resolution removing noexcept,
because libc++ does indeed have the possibility of throwing on allocation
failure.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@316941 91177308-0d34-0410-b5e6-96231b3b80d8
The guts of the increment method for recursive_directory_iterator
was failing to pass an error code object to calls to status/symlink_status,
which can throw under certain conditions.
This patch fixes the issues by correctly propagating the error codes.
However the noexcept still needs to be removed from the signature, as
mentioned in LWG 3014, but that change will be made in a separate commit.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@316939 91177308-0d34-0410-b5e6-96231b3b80d8
I *did* try to check that such kind of an issue was not introduced
by the rL315874, but clearly i failed to finish verification.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@315876 91177308-0d34-0410-b5e6-96231b3b80d8
Previously this broke the builders, when D38101 was committed.
Silence the warning so that it can be re-landed.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@315874 91177308-0d34-0410-b5e6-96231b3b80d8
Clang recently changed the way it outputs static assert diagnostics.
This patch fixes libc++'s -verify tests so they tolerate both the old
and new message format.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@313499 91177308-0d34-0410-b5e6-96231b3b80d8
This makes them consistent (many comments already used uppercase).
The special REQUIRES, UNSUPPORTED, and XFAIL comments are excluded from this change.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@309468 91177308-0d34-0410-b5e6-96231b3b80d8
This patch speculatively implements the PR for LWG 2937, which fixes
two issues with equivalent.
(1) It makes equivalent("dne", "exists") an error. Previously only
equivalent("dne", "dne") was an error and the former case was not (it returned false).
Now equivalent reports an error when either input doesn't exist.
(2) It makes equivalent(p1, p2) well-formed when `is_other(p1) && is_other(p2)`.
Previously this was an error, but there is seemingly no reason why it should be on POSIX system.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307117 91177308-0d34-0410-b5e6-96231b3b80d8
It seems conceivable that a user would need to get a coroutine handle
having only a const reference to the promise_type, for example from
within a const member function of the promise.
This patch allows that use case. A coroutine_handle<const T> can be used
in essentially the same way a coroutine_handle<T>, ie to start and destroy
the coroutine. The constness of the promise doesn't/shouldn't propagate
to the handle.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305536 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r304462, thereby re-enabling two tests under ubsan.
We expect these tests to pass now that PR33271 is fixed.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304580 91177308-0d34-0410-b5e6-96231b3b80d8
