- 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.
This will allow adding bare compiler flags through the new
configuration DSL. Previously, this would have required adding
a Lit feature for each such flag.
Differential Revision: https://reviews.llvm.org/D90429
The explicit call to `std::setlocale(LC_ALL, "C")` isn't required, since
the Standard already says the equivalent of this call is performed on
program startup.
On windows, the previous path replacement using forward slashes wouldn't
work, and so we'd end up including the same file again. We would do that
until we'd hit the recursion limit of the Python interpreter.
Instead, use `os.path` to properly replace without assuming a specific
path separator.
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 variable declarations interleaved with logic was really difficult
to read. Instead, simply have two different implementations for _WIN32
and others.
This is a massive revert of the following commits (from most revent to oldest):
2b9b7b5775.
529ac3319728270234f169c2087283b5aa67446e5d796645d6
After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.
These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.
See https://reviews.llvm.org/D89041 for more details on this adventure.
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
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.
Differential Revision: https://reviews.llvm.org/D89041
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
Differential Revision: https://reviews.llvm.org/D89041
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
This is defined both by libcxx/utils/libcxx/test/config.py (for
any windows target) and msvc_stdlib_force_include.h (when testing
specifically the MSVC C++ library).
The command line define (-D_CRT_SECURE_NO_WARNINGS) defines it to the
value 1; change the header define to match that.
Keeping both instances, to keep the fix for cases when not building
in cases that don't use config.py.
Also remove a comment about whether this can be removed; it can't at
least be removed altogether - doing that breaks a number of tests that
otherwise succeed.
Differential Revision: https://reviews.llvm.org/D89588
Use `__FUNCSIG__` instead when compiling with MSVC. While we're touching `makeTypeIDImp`, remove the warning suppression for C4640 "construction of local static object is not thread safe" since C1XX now correctly constant-initializes `id`.
The Standard doesn't include the
```c++
template<class T>
T* atomic_fetch_meow(atomic<T*>, ...);
```
templates these tests are testing.
(See https://bugs.llvm.org/show_bug.cgi?id=47908)
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
Use .string() instead of .native() in places where we want to combine
paths with std::string.
Convert some methods to take a fs::path as parameter instead of
std::string, for cases where they are called with paths as
parameters (which can't be implicitly converted to std::string if
the path's string_type is wstring).
Differential Revision: https://reviews.llvm.org/D89530
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
It appears that the released version of clang that supports constexpr
destructors is clang 10 and the oldest one that accepts -std=c++2a is 5,
so mark these as UNSUPPORTED for clang-5 to clang-9.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D89704
Define all the fuzzing tests in libcxx/test/libcxx/fuzzing, and get
rid of the ad-hoc libcxx/fuzzing directory, which wasn't properly
integrated with the build system or test suite.
As a fly-by change, this also reduces the dependencies of fuzzing tests
on large library components like <iostream>, to make them work on more
platforms.
This changes the checking for available locales to use one program that
iterates over argv to test multiple locale names instead of checking each
name with a separate executable.
This massively speeds up running individual tests using an SSH executor
(it can take up to 10 seconds to compile and run a single test in some
emulated environments) in case no locales are installed since then all
fallback names are tested idividually. But even on a native machine
this reduces the libc++ lit startup time by ~1-2 second for me on a machine
that does not have locale data installed.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88884
On FreeBSD we get the following error when passing zero as the requested
alignment: error: requested alignment is not a power of 2
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88820
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
Instead of having this script be part of the OSS-Fuzz repository, I think
it makes more sense to have it alongside the rest of the fuzzing targets
in libc++.
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
rGcc69d211d0d65d7b introduced several uses of `printf` with format
directives `%lu` and `%ld` to format values of type `size_t` and
`ptrdiff_t` respectively.
That doesn't reliably work in all C implementations, because those
types aren't necessarily the same thing as 'long int': sometimes
they're not even the same size, and when they are the same size, they
might be officially defined as int rather than long (for example),
which causes clang to emit a diagnostic for the mismatch.
C has special-purpose printf modifier letters for these two types, so
it's safer to use them. Changed all `%lu` on `size_t` to `%zu`, and
all `%ld` on `ptrdiff_t` to `%td`.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D89545
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.
Also, some tests had multiple death tests in them, so split them into
separate tests instead. The second death test would obviously never
get run, because the first one would kill the program before.
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.
To make it clearer this is about whether the library supports the debug
mode at all, not whether the debug mode is enabled. Per comment by Nico
Weber on IRC.
To make sure we don't store a mutable object (which could be modified by
outside code without us noticing) as the cache key, we pickle the cache
key to get a byte stream. If two keys are unequal, we know for sure they
will not have the same pickling. And if they are equal, there's a large
chance they will have the same pickling. If they don't, we might end up
not reusing a cached entry when we could have, but at least the behavior
we'll have is semantically correct.
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.
glibc supports versioning, so it's possible to build against older
version and run against newer version. This is sometimes relied on
in practice, e.g. in Fuchsia build we build against older sysroot
(equivalent to Ubuntu Trusty) to cover the broadest possible range
of host systems, but that doesn't necessarily match the system that
binary is going to run on which may have newer version, in which case
the compile test used in curr_symbol is going to fail. Using runtime
check is more reliable. This is a follow up to D56702 which addressed
one instance, this patch addresses all of the remaining ones.
Differential Revision: https://reviews.llvm.org/D88188
Some libc++ builds may want to disable support for the debug mode,
for example to reduce code size or because the current implementation
of the debug mode requires a global map. This commit adds the
LIBCXX_ENABLE_DEBUG_MODE CMake option and ties it into the test
suite.
It also adds a CI job to test this configuration going forward.
Differential Revision: https://reviews.llvm.org/D88923
These tests were only being run when _LIBCPP_DEBUG was defined, which
isn't the case by default when we run the test suite. In other words,
all these debug mode tests were never being run. This commit makes sure
they are run, and in some cases, extracts them into a file under test/libcxx
to separate them from the Standard tests.
Differential Revision: https://reviews.llvm.org/D88836
* Use an empty struct instead of a member pointer to represent this
type, so that we don't actually pass a zero member pointer at runtime.
* Mark the constructor as consteval to ensure that no code is emitted
for it whenever possible.
* Add a honeypot constructor to reject all non-int arguments, so that
the only argument that can arrive at the real constructor is the
literal 0.
This results in better generated code, and rejecting invalid comparisons
against nullptr, 0L, and so on, while also rejecting invalid comparisons
against (1-1) and similar that would be allowed if we required an
integer constant expression with value 0.
Differential Revision: https://reviews.llvm.org/D85051
After rebasing my trivially-relocatable branch, this behavior was broken...
but no libc++ unit test caught it! Add a regression test specifically for
erasing out of a vector.
Differential Revision: https://reviews.llvm.org/D88421
We're technically not allowed by the Standard to call ::operator new in
constexpr functions like __libcpp_allocate. Clang doesn't seem to complain
about it, but GCC does.
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
This commit adds std::construct_at, and marks various members of
std::allocator_traits and std::allocator as constexpr. It also adds
tests and turns the existing tests into hybrid constexpr/runtime tests.
Thanks to Richard Smith for initial work on this, and to Michael Park
for D69803, D69132 and D69134, which are superseded by this patch.
Differential Revision: https://reviews.llvm.org/D68364
Louis Dionne