When building the runtimes, it's very important not to add rpaths unless
the user explicitly asks for them (the standard way being CMAKE_INSTALL_RPATH),
or to change the install name dir unless the user requests it (via
CMAKE_INSTALL_NAME_DIR).
llvm_setup_rpath() would override the install_name_dir of the runtimes
even if CMAKE_INSTALL_NAME_DIR was specified to something, which is wrong
and in fact even "dangerous" for the runtimes.
This issue was discovered when trying to build libc++ and libc++abi as
system libraries for Apple, where we set the install name dir to /usr/lib
explicitly. llvm_setup_rpath() would cause libc++ to have the wrong install
name dir, and for basically everything on the system to fail to load.
This was discovered just now because we previously used something closer
to a standalone build, where llvm_setup_rpath() wouldn't exist, and hence
not be used.
This is a revert of the following commits:
libunwind: 3a667b9bd8
libc++abi: 4877063e19
libc++: 88434fe05f
Those added llvm_setup_rpath() for consistency, so it seems reasonable
to revert.
Differential Revision: https://reviews.llvm.org/D91099
Summary:
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.
Also, add XFAIL markup to flag expected errors.
The current way we test this is pretty cheap, i.e. we download previously
released macOS dylibs and run against that. Ideally, we would require a
full host running the appropriate version of macOS, and we'd execute the
tests using SSH on that host. But since we don't have such hosts available
easily for now, this is better than nothing.
At the same time, also fix some tests that were failing when back
deploying.
Differential Revision: https://reviews.llvm.org/D90869
Remove Phabricator, which isn't needed anymore since we don't report
the job results ourselves. Also, install python3-sphinx instead of
sphinx-doc, since the latter doesn't provide the sphinx-build binary.
Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the headers
will by default prevent you from using some features that were not
released in the dylib on your target platform. This is a source of
frustration since people building libc++ from sources are usually not
trying to use some vendor's released dylib.
For that reason, I've been thinking for a long time that availability
annotations should be off by default, which is the primary change that
this commit enables.
In addition, it reworks the implementation to make it easier for new
vendors to add availability annotations for their platform, and it
refreshes the documentation to reflect the current state of the codebase.
Finally, a CMake configuration option is added to control whether
availability annotations should be turned on for the flavor of libc++
being created. The intent is for vendors like Apple to turn it on, and
for the upstream libc++ to leave it off (the default).
Differential Revision: https://reviews.llvm.org/D90843
This undefined behavior was found by applying Lénárd Szolnoki's proposal
to disable implicit conversion of default_delete<D> to default_delete<B>.
The offending part of the test is circa line 243.
The wording that makes it undefined behavior is http://eel.is/c++draft/expr.delete#3 .
Differential Revision: https://reviews.llvm.org/D90536
`mftb` and `mftbl` are equivalent, there is no need to have two names for doing the same thing, rename `mftbl` to only have `mftb`.
Differential Revision: https://reviews.llvm.org/D89506
Those are part of the library, and shipping them just adds a tiny bit of
size to the distribution. This was originally added in b422ecc7de to
make it possible to match the Makefile build, which doesn't exist anymore.
The upside is build system simplification.
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.
Unfortunately, executing these tests correctly on platforms that do not
support a shell is very challenging. Since the executor can't just negate
the result of the command, we'd have to ship a portable program capable
of running the actual test executable, and negating its result.
Doing this portably is challenging. Since we do not currently have strong
use cases for tests that fail at runtime (we effectively have no tests
using that capability right now), it is difficult to justify making them
work portably. Instead, it makes more sense to remove this feature until
we can implement it properly (i.e. without requiring shell support).
If __libcpp_mbsrtowcs_l outputs zero wchar_t's for week days or
month names (due to errors in the locale function setup), these are
matched all the time in __time_get_storage::__analyze, ending up in
an infinite loop, allocating more memory until killed.
Differential Revision: https://reviews.llvm.org/D69553
Previously, these had to be set manually when building each of the
projects standalone, in order to get proper symbol visibility when
combining the two libraries.
Differential Revision: https://reviews.llvm.org/D90021
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
So far, most actual uses of libc++ std::filesystem probably use
the sendfile or fcopyfile implementations.
Differential Revision: https://reviews.llvm.org/D90601
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
The strings were concatenated together without adding spaces between
numbers, which lead to numbers that wouldn't fit in an unsigned int.
Thanks to Casey Carter for the find.
This makes us closer to running the test suite on platforms where the
legacy test suite configuration doesn't work.
One notable change after this commit is that the tests will be run with
warnings enabled on GCC too, which wasn't the case before. However,
previous commits should have tweaked the test suite to make sure it
passes with warnings enabled on GCC.
Note that warnings can still be disabled with `--param enable_warnings=False`,
as before.
Differential Revision: https://reviews.llvm.org/D90432
Instead of having to remember the command-line to use every time, this
commit adds a CMake target to generate the ABI list in the current
configuration, if it is supported.
As a fly-by change, remove scripts that are now unused (sym_match.py
and sym_extract.py).
Before 6db314e86b, when running cmake with clang, libcxx, and
compiler-rt enabled, building `ninja all` would run the
generate-cxx-headers target, due to the sanitizers depending on it.
After 6db314e86b, if LIBCXX_ENABLE_SHARED and LIBCXX_ENABLE_STATIC
and LIBCXX_INCLUDE_TESTS and LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY are
disabled (https://reviews.llvm.org/D82702#2153627), `ninja all`
no longer copies the libcxx headers, which means clang can't compile
programs like `#include <string>` on macOS.
Explicitly add the copy target to the all target to restore the old
behavior.
GCC tries to be nice and tell us that we probably want to also implement
sized deallocation functions when we override the normal ones. However,
we know what we're doing in the test suite and don't want to override
them.
- 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
This patch add the target-* (x86_64-*) as used elsewhere in llvm.
Reviewed By: #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D88027
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, wchar_t is 16 bit, while we might be widening chars to
char32_t.
This cast had been present since the initial commit, and removing it
doesn't seem to make any tests fail.
Differential Revision: https://reviews.llvm.org/D90228
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.
On old Apple platforms (pre 10.9), we couldn't rely on the iostreams
explicit instantiations being part of the dylib. However, we don't
support back-deploying to such old deployment targets anymore, so the
workaround can be dropped.
Now libc++ pipeline will be triggered from the "premerge-checks" and the
combined result are going to be returned to Harbormaster.
Reviewed-by: ldionne
Differential Revision: https://reviews.llvm.org/D89113
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
This commit should really be named "Workaround external projects depending
on libc++ build system implementation details". It seems that the compiler-rt
build (and perhaps other projects) is relying on the fact that we copy libc++
and libc++abi headers to `<build-root>/include/c++/v1`. This was changed
by 5d796645, which moved the headers to `<build-root>/projects/libcxx/include/c++/v1`
and broke the compiler-rt build.
I'm committing this workaround to fix the compiler-rt build, but we should
remove reliance on implementation details like that. The correct way to
setup the compiler-rt build would be to "link" against the `cxx-headers`
target in CMake, or to run `install-cxx-headers` using an appropriate
installation prefix, and then manually add a `-I` path to that location.
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
This patch ensures that __shared_weak_count provides a consistent vtable
regardless of if RTTI is enabled or if we are targeting a static or shared
libc++ build.
This patch is technically ABI breaking, but only for a very specific
configuration that no vendor should be shipping.
Note that _LIBCPP_BUILD_STATIC is not normally defined when building
libc++.a, but instead it must be manually provided by the user or the
__config_site.
Differential Revision: https://reviews.llvm.org/D32838
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.
Previously, we would define new/delete in both libc++ and libc++abi.
Not only does this cause code bloat, but also it's technically an ODR
violation since we don't know which operator will be selected. Furthermore,
since those are weak definitions, we should strive to have as few of them
as possible (to improve load times).
My preferred choice would have been to put the operators in libc++ only
by default, however that would create a circular dependency between
libc++ and libc++abi, which GNU linkers don't handle.
Folks who want to ship new/delete in libc++ instead of libc++abi are
free to do so by turning on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS at
CMake configure time.
On Apple platforms, this shouldn't be an ABI break because we re-export
the new/delete symbols from libc++abi. This change actually makes libc++
behave closer to the system libc++ shipped on Apple platforms.
On other platforms, this is an ABI break for people linking against libc++
but not libc++abi. However, vendors have been consulted in D68269 and no
objection was raised. Furthermore, the definitions can be controlled to
appear in libc++ instead with the CMake option.
Differential Revision: https://reviews.llvm.org/D68269
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
We included <istream> and <ostream> from <random>, but really it is
sufficient to include <iosfwd> if we make sure we access ios_base
members through a dependent type. This allows us to break a hard
dependency of <random> on locales.
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.
Remove check for standalone and shared library mode in libcxxabi to
allow including tests in said mode. This check prevented running the
tests in standalone mode with static libraries, which is the case for
baremetal targets.
Fix check-unwind target trying to use a non-existent llvm-lit executable
in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to
libunwind in order to make the tests work in standalone mode.
Reviewed By: ldionne, #libc_abi, #libc
Differential Revision: https://reviews.llvm.org/D86540
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.
There are several places in LLVM's CMake setup that try to remove the
`stdlib=...` flag from the CMake flags. All this code however only considered
the `-stdlib=` variant of the flag but not the alternative spelling with a
double dash. This causes that when one adds `--stdlib=...` to the user-provided
CMake flags that this gets transformed into just `-` which ends up causing the
build system to think it should read the source from stdin (which then lead to
very confusing build errors).
This just adds the alternative spelling before the`-stdlib=` variant in all
these places
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D87133
This simplifies the workflow for adding new feature-test macros for
contributors. Previously, they would have to move the generated <version>
header from a temporary directory to libc++'s include directory by hand.
This makes the behavior for the <version> header consistent with what's
done for the tests and the documentation.
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.
Due to the need to support compilers that implement builtin operator
new/delete but not their align_val_t overloaded versions, there was a
lot of complexity. By assuming that a compiler that supports the builtin
new/delete operators also supports their align_val_t overloads, the code
can be simplified quite a bit.
Differential Revision: https://reviews.llvm.org/D88301
Louis Dionne