Check a different set of env vars, don't check the exact value
of the fallback path. (GetTempPath falls back to returning the Windows
folder if nothing better is available in env vars.)
The test still fails one check on windows (due to relying on perms::none),
which will be addressed separately.
Differential Revision: https://reviews.llvm.org/D98139
On windows, the path internal representation is wchar_t, and
input/output often goes through utf8 inbetween, which causes extra
allocations.
MS STL also fails a number of strict allocation checks, so this
shouldn't be a standards compliance issue.
Differential Revision: https://reviews.llvm.org/D98398
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 156180727d.
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
Check that appends with a path object doesn't do allocations, even
on windows.
Suggested by Marek in D98398. The patch might apply without D98398
(depending on how much of the diff context has to match), but doesn't
make much sense until after that patch has landed.
Differential Revision: https://reviews.llvm.org/D98412
This makes sure that no extra allocations happen on windows, fixing
earlier errors in the DisableAllocationGuard (in the second case that
is modified).
This is split out from D98398.
Differential Revision: https://reviews.llvm.org/D98406
This test was previously tweaked in
321f696920 to match the output of
of MS STL (except that the MS STL fails on the testcase with an
empty path).
libc++ doesn't produce paths with all normalized separators (and the
spec doesn't mandate it to either).
Tweak the test reference to match exactly what libc++ produces. If
testing with a non-libc++ library, do a relaxed comparison that allows
the separators to differ.
Differential Revision: https://reviews.llvm.org/D98215
Don't use the mode_t type - the official windows sdk doesn't have that type.
(Mingw headers does have such a typedef though.) The umask function returns
int on windows, in both header variants.
Thus just use auto to deduce the umask return type automatically.
Differential Revision: https://reviews.llvm.org/D98140
Use "expect" instead of "output" for generating "proximate_expected",
pass the arguments to PathEq in the same order as above, rename the
"proximate_expected" variable to be consistent with the naming of the
earlier "expect", use .empty() instead of .native().empty().
Differential Revision: https://reviews.llvm.org/D98127
Convert the expected result path to preferred separators, add exceptions
to the test results where needed (due to some cases being interpreted
as a root name).
Differential Revision: https://reviews.llvm.org/D98106
Add ifdefs to the test reference tables for cases where paths are
interpreted differently (paths that contain a root name).
Fix test assumptions regarding has_root_name() and is_absolute() and
add logic to verify the results of is_absolute() for the test cases in
the table.
Also add a testcase for the path "//net/", which seemed like an
omission.
Differential Revision: https://reviews.llvm.org/D89943
This makes sure that it actually tests the right compare() overloads
in windows configurations.
This also fixes the allocation guards that enforce no allocations
while running the compare() functions.
Differential Revision: https://reviews.llvm.org/D97551
Restructure code in directory_entry.obs/file_type_obs.pass.cpp
and directory_entry.obs/hard_link_count.pass.cpp to reduce the
amount of ifdeffery needed.
In file_type_obs.pass.cpp, we can't inline the calls to
env.create_* into the lambda calls (e.g. "test_path(env.create_*())"),
because the lambda removes the referenced file, and the hardlink
must be created while the earlier test file exists.
In hard_link_count.pass.cpp, move restoration of the original
directory permissions to the end of the lambda, so that new
directory entries can be created after the lambda has run once.
Differential Revision: https://reviews.llvm.org/D89948
On Windows, path::value_type is wchar_t, so one can't pass the return
value of path::c_str() directly to std::remove().
This matches what was done for tests under std/input.output/filesystems
in 81db3c31aa and
3784bdf217.
Differential Revision: https://reviews.llvm.org/D97458
This makes the symlinks work properly on windows.
A similar round of cleanup was done in
c41bda7f5f, but these tests were
added after that.
Differential Revision: https://reviews.llvm.org/D97089
The spec doesn't declare it as an enum class, and being declared
as an enum class breaks referring to the values as e.g.
path::auto_format.
Differential Revision: https://reviews.llvm.org/D97084
These don't seem to have any function in the test.
The non_regular_file one seems to have been added in
0f8c8f59df, without any apparent
purpose there.
Differential Revision: https://reviews.llvm.org/D97083
This matches what MS STL returns; in std::filesystem, forward slashes
are considered generic dir separators that are valid on all platforms.
Differential Revision: https://reviews.llvm.org/D91181
The root_path function has to be changed to return the parsed bit
as-is; otherwise a path like "//net" gets a root path of "//net/", as
the root name, "//net", gets the root directory (an empty string) appended,
forming "//net/". (The same doesn't happen for the root dir "c:" though.)
Differential Revision: https://reviews.llvm.org/D91178
Before this patch, feature-test macros didn't take special availability
markup into account, which means that feature-test macros can sometimes
appear to "lie". For example, if you compile in C++20 mode and target
macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided
even though the <filesystem> declarations are marked as unavailable.
This patch fixes that.
rdar://68142369
Differential Revision: https://reviews.llvm.org/D94983
The MS STL does even more cleanup (corresponding to lexically_normal
I think), but this seems to be the very minimum needed for making the
symlinks work when the target path contains non-native paths.
Differential Revision: https://reviews.llvm.org/D91145
P1614R2 removes most of `directory_entry`'s member comparison operators, leaving only `operator==` and `operator<=>`. This test should require the comparison expressions to be valid rather than require the member functions to be present so it is correct in both C++17 and C++20 modes.
Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem
support was compiled into libc++'s library. This commit promotes the
setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where
the whole library is aware of the setting and features that depend on
<filesystem> won't be provided at all. The test suite is also properly
annotated such that tests that depend on <filesystem> are disabled when
the library doesn't support it.
This is an alternative to https://llvm.org/D94824, but also an improvement
along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to
make for a while.
Differential Revision: https://reviews.llvm.org/D94921
It was added in commit 0b71bf7939, "[libcxx] [test] Add a test for conversions between wchar_t, utf8, char16_t, char32_t and windows native narrow code pages"
This implements the std::filesystem parts of P0482 (which is already
marked as in progress), and applies the actions that are suggested
in P1423.
Differential Revision: https://reviews.llvm.org/D90222
Some executors do not run the tests in a shell, and so assuming that
they can understand shell builtins is wrong. Instead, call Bash
directly to do what we need to do.
This still requires the executor to be able to run Bash, but at least
it does not require it to interpret command lines in the Bash language.
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
Prepend the root path on the already_absolute testcase, and construct
a path ending with the preferred separator for the test reference for
"foo/".
Differential Revision: https://reviews.llvm.org/D89944
- Several -Wshadow warnings
- Several places where we did not initialize our base class explicitly
- Unused variable warnings
- Some tautological comparisons
- Some places where we'd pass null arguments to functions expecting
non-null (in unevaluated contexts)
- Add a few pragmas to turn off spurious warnings
- Fix warnings about declarations that don't declare anything
- Properly disable deprecation warnings in ext/ tests (the pragmas we
were using didn't work on GCC)
- Disable include_as_c.sh.cpp because GCC complains about C++ flags
when compiling as C. I couldn't find a way to fix this one properly,
so I'm disabling the test. This isn't great, but at least we'll be
able to enable warnings in the whole test suite with GCC.
When porting libc++ to embedded systems, it can be useful to drop support
for localization, which these systems don't implement or care about.
Differential Revision: https://reviews.llvm.org/D90072
The individual enum values in copy_options and file_type aren't
specified in the standard.
The standard doesn't require fs::path::format to be a scoped enum.
Differential Revision: https://reviews.llvm.org/D89866
Split the resolution check to a separate test, which is marked as
unsupported on windows.
On windows (both with MS STL and libstdc++), the file time has
100 ns resolution; the standard doesn't mandate a specific resolution.
Differential Revision: https://reviews.llvm.org/D89535
Use p.string() instead of p.native() for comparing with the expected
value.
Explicitly list the expected values for both posix and windos, even if
the operation is an identity operation on posix.
Differential Revision: https://reviews.llvm.org/D89532
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
Mark this as a libcpp specific test; the standard doesn't say that
this method should be noexcept.
Differential Revision: https://reviews.llvm.org/D89677
The standard doesn't declare this overload as noexcept, but doesn't
either say that it strictly cannot be noexcept either. The function
doesn't throw on errors that are signaled via error_code, but the
standard says that it may throw a bad_alloc.
This fixes an error with libstdc++ on linux.
Differential Revision: https://reviews.llvm.org/D89678
This makes them more readable in llvm-lit's output on failures.
This only applies the change on the filesystem test subdir.
Differential Revision: https://reviews.llvm.org/D89680
Use string() for convenience for testing where possible, but keep using
native() for move tests where we want to check that no allocations are
made, constructing a reference fs::path::string_type instead.
Use the right value_type in a few places.
Make the synop test check for the right types and for the expected
preferred separator.
Differential Revision: https://reviews.llvm.org/D89537
This fixes building with libstdc++ for windows. MS STL has got
ifstream/ofstream overloads that taken wide strings though.
Differential Revision: https://reviews.llvm.org/D89539
Some platforms, like several embedded platforms, do not provide a source
of randomness through a random device. This commit makes it possible to
build and test libc++ for such platforms, i.e. without std::random_device.
Surprisingly, the only functionality that doesn't work on such platforms
is std::random_device itself -- everything else in <random> still works,
one just has to find alternative ways to seed the PRNGs.
While this adds some convenience to the test suite, it prevents the tests
using these checkpoints from being used on systems where signals are not
available, such as some embedded systems. It will also prevent these tests
from being constexpr-friendly once e.g. std::map is made constexpr, due
to the use of statics.
Instead, one can always use a debugger to figure out exactly where a
test is failing when that isn't clear from the log output without
checkpoints.
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.
This is needed when running the tests in Freestanding mode, where main()
isn't treated specially. In Freestanding, main() doesn't get mangled as
extern "C", so whatever runtime we're using fails to find the entry point.
One way to solve this problem is to define a symbol alias from __Z4mainiPPc
to _main, however this requires all definitions of main() to have the same
mangling. Hence this commit.
fdc41e11f was reverted in e46c1def5 because it broke the C++11 build.
We shouldn't be using enable_if_t in C++11, instead we must use
enable_if<...>::type.
This reverts commit fdc41e11f9. It causes the
libcxx/modules/stds_include.sh.cpp test to fail with:
libcxx/include/ostream:1039:45: error: no template named 'enable_if_t'; did you mean 'enable_if'?
template <class _Stream, class _Tp, class = enable_if_t<
Still investigating what's causing this and reverting in the meantime to get
the bots green again.
Libc++ had an issue where nonsensical code like
decltype(std::stringstream{} << std::vector<int>{});
would compile, as long as you kept the expression inside decltype in
an unevaluated operand. This turned out to be that we didn't implement
LWG1203, which clarifies what we should do in that case.
rdar://58769296
When statically linking libc++ on some systems, the streams are not
initialized early enough, which causes all kinds of issues. This was
reported e.g. in http://llvm.org/PR28954, but also in various open
source projects that use libc++.
Fixes http://llvm.org/PR28954.
Differential Revision: https://reviews.llvm.org/D31413
This test tries to create a 2 GiB std::string, catching the bad_alloc
exception if the allocation fails. However, for no-exceptions builds
there is no way for the error to be reported, so this crashes with a
null pointer dereference.
Differential revision: https://reviews.llvm.org/D87682
Instead of passing file dependencies individually, assume that the
whole content of the unique test directory is a dependency. This
simplifies the test harness significantly, by making %T the directory
that contains everything required to run a test. This also removes the
need for the %{file_dependencies} substitution, which is removed by this
patch.
Furthermore, this patch also changes the harness to execute tests locally
inside %T, so as to avoid creating a separate directory for no purpose.
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
When running on remote hosts, we need the whole `echo 123 | %t.exe` command
to run on the remote host. Thus, we need to escape the pipe to make sure
the command is treated as `{ echo 123 | %t.exe } > %t.out` instead of
`{ echo 123 } | %t.exe > %t.out`m where only `echo 123` is run on the
remote host.
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
Tests that require support for Clang-verify are already marked as such
explicitly by their extension, which is .verify.cpp. Requiring the use
of an explicit Lit feature is, after thought, not really helpful.
This is a change in design: we have been bitten in the past by tests not
being enabled when we thought they were. However, the issue was mostly
with file extensions being ignored. The fix for that is not to blindly
require explicit features all the time, but instead to report all files
that are in the suite but that don't match any known test format. This
can be implemented in a follow-up patch.
Marked unsupported for C++03 and C++11 since this test uses alias
declarations, and at least one C++03 bot was failing with
-Wc++11-extensions.
Change-Id: I8c3a579edd7eb83e0bc74e85d116b68f22400161
By renaming .fail.cpp tests that don't need clang-verify to .compile.fail.cpp,
the new test format will not try to compile these tests with clang-verify,
and the old test format will work just the same. However, this allows
removing a workaround that requires parsing each test looking for
clang-verify markup.
After this change, a .fail.cpp test should always have clang-verify markup.
When clang-verify is not supported by the compiler, we will just check that
these tests fail to compile. When clang-verify is supported, these tests
will be compiled with clang-verify whether they have markup or not (so
they should have markup, or they will fail).
This simplifies the test suite and also ensures that all of our .fail.cpp
tests provide clang-verify markup. If it's impossible for a test to have
clang-verify markup, it can be moved to a .compile.fail.cpp test, which
are unconditionally just checked for compilation failure.
The libc++ test suite currently defines several features that are not
used anywhere in the tests, or that are redundant with other features.
For the purpose of simplifying config.py and to ease the bring up of a
new configuration, this commit removes some of these features:
- rename dylib-has-no-filesystem to c++filesystem-disabled, which exists
- rename apple-darwin to just darwin, which is already set
- remove useless setting of libstdc++, which is already set correctly
- remove libcpp-abi-unstable, which is not used anywhere
- remove the glibc-XXX features, which are not used anywhere
The libc++ test suite has a lot of old Lit features used to XFAIL tests
and mark them as UNSUPPORTED. Many of them are to workaround problems on
old compilers or old platforms. As time goes by, it is good to go and
clean those up to simplify the configuration of the test suite, and also
to reflect the testing reality. It's not useful to have markup that gives
the impression that e.g. clang-3.3 is supported, when we don't really
test on it anymore (and hence several new tests probably don't have the
necessary markup on them).
Broke builders that emit different diagnostics. e.g.:
error: 'warning' diagnostics seen but not expected:
Line 13: alias declarations are a C++11 extension
Line 20: alias declarations are a C++11 extension
This reverts commit ff87813715.
The testing script used to test libc++ historically did not like directories
without any testing files, so these tests had been added. Since this is
not necessary anymore, we can now remove these files. This has the benefit
that the total number of tests reflects the real number of tests more
closely, and we also skip some unnecessary work (especially relevant when
running tests over SSH).
However, some nothing_to_do.pass.cpp tests actually serve the purpose of
documenting that an area of the Standard doesn't need to be tested, or is
tested elsewhere. These files are not removed by this commit.
Removal done with:
import os
import itertools
for (dirpath, dirnames, filenames) in itertools.chain(os.walk('./libcxx/test'),
os.walk('./libcxxabi/test')):
if len(filenames + dirnames) > 1 and \
any(p == 'nothing_to_do.pass.cpp' for p in filenames):
os.remove(os.path.join(dirpath, 'nothing_to_do.pass.cpp'))
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.
Martin Storsjö