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
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
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
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
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
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
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
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.
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
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.
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).
Forcing -Werror and other warnings means that the test suite isn't
actually testing what most people are seeing in their code -- it seems
better and less arbitrary to compile these tests as close as possible
to the compiler default instead.
Removing -Werror also means that we get to differentiate between
diagnostics that are errors and those that are warnings, which makes
the test suite more precise.
Differential Revision: https://reviews.llvm.org/D76311
Some tests do not fail at all when -verify is not supported, unless some
arbitrary warning flag is added to make them fail. We currently used
-Werror=unused-result to make them fail, but doing so makes the test
suite a lot more inscrutable. It seems better to just disable those
tests when -verify is not supported.
Differential Revision: https://reviews.llvm.org/D76256
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
Summary:
Freestanding is *weird*. The standard allows it to differ in a bunch of odd
manners from regular C++, and the committee would like to improve that
situation. I'd like to make libc++ behave better with what freestanding should
be, so that it can be a tool we use in improving the standard. To do that we
need to try stuff out, both with "freestanding the language mode" and
"freestanding the library subset".
Let's start with the super basic: run the libc++ tests in freestanding, using
clang as the compiler, and see what works. The easiest hack to do this:
In utils/libcxx/test/config.py add:
self.cxx.compile_flags += ['-ffreestanding']
Run the tests and they all fail.
Why? Because in freestanding `main` isn't special. This "not special" property
has two effects: main doesn't get mangled, and main isn't allowed to omit its
`return` statement. The first means main gets mangled and the linker can't
create a valid executable for us to test. The second means we spew out warnings
(ew) and the compiler doesn't insert the `return` we omitted, and main just
falls of the end and does whatever undefined behavior (if you're luck, ud2
leading to non-zero return code).
Let's start my work with the basics. This patch changes all libc++ tests to
declare `main` as `int main(int, char**` so it mangles consistently (enabling us
to declare another `extern "C"` main for freestanding which calls the mangled
one), and adds `return 0;` to all places where it was missing. This touches 6124
files, and I apologize.
The former was done with The Magic Of Sed.
The later was done with a (not quite correct but decent) clang tool:
https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed
This works for most tests, though I did have to adjust a few places when e.g.
the test runs with `-x c`, macros are used for main (such as for the filesystem
tests), etc.
Once this is in we can create a freestanding bot which will prevent further
regressions. After that, we can start the real work of supporting C++
freestanding fairly well in libc++.
<rdar://problem/47754795>
Reviewers: ldionne, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57624
llvm-svn: 353086
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 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
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
Martin Storsjö