This patch adds caching of file attributes during directory iteration
on Windows. This improves the performance when working with files being
iterated on in a directory.
On Windows you can not create symlinks without elevated privileges
unless you have Windows developer mode enabled. There's ~67 libcxx tests
that run into failures on windows if your environment is not set up
correctly (Go to windows settings and enable "developer mode").
This change:
- Adds a feature check for whether the host can create symlinks. (see
libcxx/utils/libcxx/test/features.py)
- Mark the feature as required for the 67 tests that hit failures on
windows due to this. This will allow lit to correctly mark these tests
as unsupported instead of unexpectedly failed (this is helpful since
then you know you didn't break something with your change, it's just
that it's not supported with your environment).
<filesystem> is a C++17 addition. In C++11 and C++14 modes, we actually
have all the code for <filesystem> but it is hidden behind a non-inline
namespace __fs so it is not accessible. Instead of doing this unusual
dance, just guard the code for filesystem behind a classic C++17 check
like we normally do.
Mark tests as necessary to accommodate Android L (5.0 / API 21) and up.
Add three Android lit features:
- android
- android-device-api=(21,22,23,...)
- LIBCXX-ANDROID-FIXME (for failures that need follow-up work)
Enable an AIX workaround in filesystem_test_helper.h for the broken
chmod on older Android devices.
Mark failing test with XFAIL or UNSUPPORTED:
- Mark modules tests as UNSUPPORTED, matching other configurations.
- Mark a gdb test as UNSUPPORTED.
- XFAIL tests for old devices that lack an API (fmemopen).
- XFAIL various FS tests (because SELinux blocks FIFO and hard linking,
because fchmodat is broken on old devices).
- XFAIL various locale tests (because Bionic has limited locale
support). (Also XFAIL an re.traits test.)
- XFAIL some print.fun tests because the error exception has no system
error string.
- Mark std::{cin,wcin} tests UNSUPPORTED because they hang with
adb_run.py on old devices.
- Mark a few tests UNSUPPORTED because they allocate too much memory.
- notify_one.pass.cpp is flaky on Android.
- XFAIL libc++abi demangler test because of Android's special long
double on x86[-64].
N.B. The `__ANDROID_API__` macro specifies a minimum required API level
at build-time, whereas the android-device-api lit feature is the
detected API level of the device at run-time. The android-device-api
value will be >= `__ANDROID_API__`.
This commit was split out from https://reviews.llvm.org/D139147.
Fixes: https://github.com/llvm/llvm-project/issues/69270
Since LIBCXX_ENABLE_FILESYSTEM now truly represents whether the
platform supports a filesystem (as opposed to whether the <filesystem>
library is provided), we can provide a few additional classes from
the <filesystem> library even when the platform does not have support
for a filesystem. For example, this allows performing path manipulations
using std::filesystem::path even on platforms where there is no actual
filesystem.
rdar://107061236
Differential Revision: https://reviews.llvm.org/D152382
When we ship LLVM 16, <ranges> won't be considered experimental anymore.
We might as well do this sooner rather than later.
Differential Revision: https://reviews.llvm.org/D132151
All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.
Differential Revision: https://reviews.llvm.org/D121528
A number of the filesystem tests create a directory that contains a bad
symlink. On AIX recursively setting permissions on said directory will
return a non-zero value because of the bad symlink, however the
following rm -r still completes successfully. Avoid the assertion on
AIX, and rely on the return value of the remove command to detect
problems.
Differential Revision: https://reviews.llvm.org/D112086
This changes adds the pipeline config for both 32-bit and 64-bit AIX targets. As well, we add a lit feature `LIBCXX-AIX-FIXME` which is used to mark the failing tests which remain to be investigated on AIX, so that the CI produces a clean build.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D111359
Implement LWG3480 which enables `directory_iterator` and
`recursive_directory_iterator` to be both a `borrowed_range` and a
`view`.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D111644
On Windows, one can't use perms::none on a directory to trigger
failures to read the directory entries.
These remaining tests can't use GetWindowsInaccessibleDir() sensibly,
e.g. for tests that rely on toggling accessibility back and forth during
the test, or where the semantics of the dir provided by
GetWindowsInaccessibleDir() doesn't allow for running the ifdeffed tests
meaningfully.
Differential Revision: https://reviews.llvm.org/D97538
If running in a Windows Container, there is no such directory at all.
If running from within bash on Windows Server, the directory seems to
be fully accessible. (The mechanics of this isn't fully understood, and
it doesn't seem to happen on desktop versions.)
If the directory isn't available with the expected behaviour, mark those
individual tests as unsupported. (The test as a whole is considered to
pass, but the unsupported test is mentioned in a test summary printed on
stdout.)
Differential Revision: https://reviews.llvm.org/D98960
This makes no attempt yet to look into the why/what for each of them,
but makes the CI configuration useful for tracking further regressions.
After looking into each case, they can either be fixed, or converted
into UNSUPPORTED: windows or XFAIL: windows, once the cause is known
and explained.
A number of the filesystem cases can be fixed by patches that are
currently in review.
Differential Revision: https://reviews.llvm.org/D99095
Fix handling of skip_permission_denied on windows; after converting
the return value of GetLastError() to a standard error_code, ec.value()
is in the standard errc range, not a native windows error code. This
was missed in 156180727d6c347eda3ba749730707acb8a48093.
The directory "C:\System Volume Information" does seem to exist and
have these properties on most relevant contempory setups.
Differential Revision: https://reviews.llvm.org/D98166
error_code returned from functions might not be of the generic category,
but of the system category, which can have different error code values.
Use default_error_condition() to remap errors to the generic category
where possible, to allow comparing them to the expected values.
Use the ErrorIs() helper instead of a direct comparison against
an excpected value.
Differential Revision: https://reviews.llvm.org/D90602
Use fs::path as variable type instead of std::string, when the input
potentially is a path, as they can't be implicitly converted back to
string.
Differential Revision: https://reviews.llvm.org/D89674
We used <iostream> in several places where we don't actually need the
full power of <iostream>, and where using basic `std::printf` is enough.
This is better, since `std::printf` can be supported on systems that don't
have a notion of locales, while <iostream> can't.
C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
just slightly confusing, but provides no value. It's similar to allowing
both std=c++17 and std=c++1z, which we don't do.
This was discovered because we had an internal bot that ran the test
suite under both c++98 AND c++03 -- one of which is redundant.
Differential Revision: https://reviews.llvm.org/D80926
Don't use std::filesystem APIs for CWDGuard, use POSIX functions
instead. This way the tests don't rely on the correctness of
the functionality they're testing.
Differential Revision: https://reviews.llvm.org/D78200
This reverts commit 52cc8bac7780dbfb90dcc8cfe24696618eeaa06e.
As the discussion in https://reviews.llvm.org/D78200 continues, I will
revert this until we figure out what to do.
Summary:
Instead of storing `static_test_env` (with all the symlinks) in the repo, we create it on the fly to be cross-toolchain-friendly. The primary use case for this are Windows-hosted cross-toolchains. Windows doesn't really have a concept of symlinks. So, when the monorepo is cloned, those symlinks turn to ordinary text files. Previously, if we cross-compiled libc++ for some symlink-friendly system (e. g. Linux) and ran tests on the target system, some tests would fail. This patch makes them pass.
Reviewers: ldionne, #libc
Reviewed By: ldionne, #libc
Subscribers: EricWF, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D78200
Instead of storing static_test_env (with all the symlinks) in the repo,
we create it on the fly to be cross-toolchain-friendly. The primary
use case for this are Windows-hosted cross-toolchains. Windows doesn't
really have a concept of symlinks. So, when the monorepo is cloned,
those symlinks turn to ordinary text files. Previously, if we
cross-compiled libc++ for some symlink-friendly system (e. g. Linux) and
ran tests on the target system, some tests would fail. This patch makes
them pass.
Differential Revision: https://reviews.llvm.org/D78200
Instead of hardcoding absolute paths on the build-host in the executables,
use relative paths from the current working directory. Also, use
FILE_DEPENDENCIES to mark the static test env as being required by
the relevant tests.
Given a SSH executor that copies the files to the remote host properly,
the tests can be run on that remote host.
When I applied r356500 (https://reviews.llvm.org/D59152), I somehow
deleted all of filesystem's tests. I will revert r356500 and re-apply
it properly.
llvm-svn: 356505
Summary:
This patch treats <filesystem> as a first-class citizen of the dylib,
like all other sub-libraries (e.g. <chrono>). As such, it also removes
all special handling for installing the filesystem library separately
or disabling part of the test suite from the lit command line.
Reviewers: mclow.lists, EricWF, serge-sans-paille
Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59152
llvm-svn: 356500
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
