When building with modules, always enable local submodule visibility.
It used to be disabled on Apple platforms, but it seems like we want
to use the same flags on Apple and Linux now (see https://reviews.llvm.org/D74892).
This commit migrates some of the Lit features from config.py to the new
DSL. This simplifies config.py and is a first step towards defining all
the features using the DSL instead of the complex logic in config.py.
Differential Revision: https://reviews.llvm.org/D78382
The libcxx.util utilities don't work properly, and we should remove them
when we get rid of compiler.py. In particular, libcxx.util.to_string
appears to be completely broken.
The internal Lit shell requires the current working directory to exist.
This didn't show up locally because the directories were already created
by previous runs of the tests.
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.
This reverts commit 51a60ed14c, since the test still doesn't pass on
Windows. Marking the test as UNSUPORTED on Windows again until I've
figured out the problem.
Since 88af3ddb1e, libc++ will prefer Python 3 when available. It is
available on Apple platforms, so subprocess.check_output will return
bytes instead of str. This lead to comparisons against str to be false,
and the MacOS platform not being detected properly.
This allows defining Lit features that can be enabled or disabled based
on compiler support, and parameters that are passed on the command line.
The main benefits are:
- Feature detection is entirely based on the substitutions provided in
the TestingConfig object, which is simpler and decouples it from the
complicated compiler emulation infrastructure.
- The syntax is declarative, which makes it easy to see what features
and parameters are accepted by the test suite. This is significantly
less entangled than the current config.py logic.
- Since feature detection is based on substitutions, it works really
well on top of the new format, and custom Lit configurations can be
created easily without being based on `config.py`.
This commit is a reapplication of 6d58030c8c, which was reverted in
8f24c4b72f because it broke Python 3 support. This re-application
supports Python 3.
Differential Revision: https://reviews.llvm.org/D78381
Instead of using the libc++ headers provided alongside the toolchain,
use those in the sibling libcxx directory that we know is checked out.
Before the days of the monorepo, we couldn't assume that the libc++
repository was present when building libcxxabi. Since we can now make
that assumption, it's always better to use the version of libc++ that
is in lockstep with libc++abi, to avoid subtle bugs.
This allows defining Lit features that can be enabled or disabled based
on compiler support, and parameters that are passed on the command line.
The main benefits are:
- Feature detection is entirely based on the substitutions provided in
the TestingConfig object, which is simpler and decouples it from the
complicated compiler emulation infrastructure.
- The syntax is declarative, which makes it easy to see what features
and parameters are accepted by the test suite. This is significantly
less entangled than the current config.py logic.
- Since feature detection is based on substitutions, it works really
well on top of the new format, and custom Lit configurations can be
created easily without being based on `config.py`.
Differential Revision: https://reviews.llvm.org/D78381
Instead of having different names for the same Lit feature accross code
bases, use the same name everywhere. This NFC commit is in preparation
for a refactor where all three projects will be using the same Lit
feature detection logic, and hence it won't be convenient to use
different names for the feature.
Differential Revision: https://reviews.llvm.org/D78370
When the new libc++ test format was enabled, warnings were accidentally
dropped cause they were not part of the %{compile_flags} substitution.
This commit adds them back, however `-Werror` is only used for non-verify
tests (cause it doesn't make sense for verify tests).
This commit is a re-application of 20fd624380, which was reverted in
5ec6fdb058 because it broke the C++03 bot. This failure should have
been fixed in b4fb705e77.
When the new libc++ test format was enabled, warnings were accidentally
dropped cause they were not part of the %{compile_flags} substitution.
This commit adds them back, however `-Werror` is only used for non-verify
tests (cause it doesn't make sense for verify tests).
Summary:
This patch add the dataflow option to LLVM_USE_SANITIZER and documents
it.
Tested via check-cxx (wip to fix the errors).
Reviewers: morehouse, #libc!
Subscribers: mgorny, cfe-commits, libcxx-commits
Tags: #clang, #libc
Differential Revision: https://reviews.llvm.org/D78390
This was originally committed as f8452ddfcc and reverted in 7cb1aa9d93.
The issue was that shell builtins were being escaped too, and apparently
Bash won't execute a builtin when it is quoted e.g. '!'. Instead, it
thinks it's a command and it can't find it.
Re-committing the change with that issue fixed.
Cherrypick the upstream fix commit a77d5f7 onto llvm/utils/benchmark
and libcxx/utils/google-benchmark.
This fixes LLVM's 32-bit RISC-V compilation, and the issues
mentioned in https://github.com/google/benchmark/pull/955
An additional cherrypick of ecc1685 fixes some minor formatting
issues introduced by the preceding commit.
Differential Revision: https://reviews.llvm.org/D78084
Instead of creating Lit features for all __config_site macros automatically,
only do so for macros that generate features actually used in the test
suite. This makes it easier to know which ones are supported by the test
suite at a glance.
Note that the `libcpp-abi-version-vN` is dropped altogether, but it
wasn't used anywhere.
These substitutions are strongly tied to the operation of the test
format, so it makes sense to have them defined by the test format
instead of the Lit configuration. They should be defined regardless
of which configuration is in use.
The new format requires using an external shell, and as we transition
and we can simplify config.py as we transition to the new format. Also,
frankly, I'd be quite surprised if that setting was still working anyway
because we have several .sh.cpp tests that likely don't work in Lit's
internal shell.
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.
With this patch, .verify.cpp tests explicitly require clang-verify, but
no other test types require clang-verify out of the box. This will allow
making several .fail.cpp tests that don't have any clang-verify markup
to be just .compile.fail.cpp tests, which in turn should allow removing
a long standing workaround that requires parsing tests to detect whether
they have any clang-verify markup in them.
There are no such tests in the libc++ test suite, and I want to move
away from `.fail.cpp` tests (in favour of something else) too, which
require a workaround.
Instead of spamming a bunch of available features that are not actually
used anywhere, only set those that are actually used in the test suite.
In the future, this should probably be based on the target triple only,
with the ability to have wildcards in the triple.
Remove mentions of the ValgrindExecutor, which doesn't exist. That
executor is literally nowhere in the code base, so this is dead code
as far as we're concerned.
Also, inline a one-liner function that was called exactly once.
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
It has never been used, and it actually doesn't really work because it
assumes that the target supports Python. Instead, it's better to just
use `!` since we're running ShTests in system shells anyway.
Instead of creating a temporary directory inside /tmp and running the
tests there, use a directory name based on LIT's %t substitution. This
has the benefit of not hitting /tmp so much (which is slow on some
filesystems). It also has the benefit that `ninja -C build clean` will
automatically remove the artifacts even if a test somehow failed to
remove its temporary directory (I've seen this happen when CTRL-C is
received).
This allows both the old and the new testing formats to handle these
tests with modules enabled.
We also include the modules flags in the %{flags} substitution, which
means that .sh.cpp tests in the old format and all tests in the new
format will use modules flags when enabled.
The LitConfig is shared across the whole test suite. However, since
enabling recursive expansion can be a breaking change for some test
suites, it's important to confine the setting to test suites that
enable it explicitly.
Note that other issues were raised with the way recursiveExpansionLimit
operates. However, this commit simply moves the setting to the right
place -- the mechanism by which it works can be improved independently.
Differential Revision: https://reviews.llvm.org/D77415
We had a workaround because GCC 5 does not evaluate static assertions
that are dependent on template parameters. This commit removes the
workaround and marks the corresponding tests as unsupported with GCC 5.
This has the benefit of bringing the new and the old test formats closer
without having to carry a workaround for an old compiler in the new
test format.
Otherwise, we're missing some flags like the flags that are used by
sanitizer builds and the 32-bit builds. In the long term, I think it
would be better to have only %{compile_flags} and %{link_flags}, but
for the benefit of adopting the new format by default, I think it's OK
to add %{flags} to it.
On Windows, we must make sure to close the temporary tar file before we
try to scp it.
This is an alternative approach to https://reviews.llvm.org/D77500.
This new test format is simpler and more flexible. It creates Lit ShTests
on the fly that reuse existing substitutions (like %{cxx}) instead of
having complex logic in Python to run the tests. This has the benefit
that virtually no coding is required to customize how the test suite is
run -- one can achieve pretty much anything by defining the appropriate
substitutions in a simple lit.cfg file.
For example, in order to run the tests on an embedded device after
building with a specific SDK, one can set the %{cxx} and %{compile_flags}
substitutions to use that SDK, and the %{exec} substitution to the ssh.py
script currently used for .sh.cpp tests with a remote executor. Dealing with
the SSHExecutor becomes unnecessary, since all tests are treated like ShTests.
As a side effect of this design, configuration files for the test
suite can be as simple as:
config.substitutions.append(('%{cxx}', '<path-to-compiler>'))
config.substitutions.append(('%{compile_flags}', '<flags>'))
config.substitutions.append(('%{link_flags}', '<flags>'))
config.substitutions.append(('%{exec}', '<script-to-execute>'))
This should allow storing lit.cfg files for various configurations
directly in the repository instead of relying on complicated logic
in config.py to set up the right flags. I've found numerous problems
in that logic in the past years, and it seems like having simple and
explicit configuration files for the configurations we support is
going to solve most of these problems. Specifically, I am hoping to
store configuration files for testing other Standard Libraries in
the repository.
Improving the interaction with the test suite configuration is still a
work in progress, so for now this test format reuses the substitutions and
available features that are set up by the current config.py.
This new test format should support pretty much everything that the current
test format supports, however it will not be enabled by default at first to
make sure we're satisfied with it. For a short period of time, the new format
will require `--param=use_new_format=True` to be enabled, however it is a very
short term goal to replace the current testing format entirely and to simplify
the configuration accordingly.
Differential Revision: https://reviews.llvm.org/D77338
Instead of executing tests from within the libc++ test suite, we execute
them from the Lit execution directory. However, since some tests have
file dependencies, we must copy those dependencies to the execution
directory where they are executed.
This has the major benefit that if a test modifies a file (whether it
is wanted or not), other tests will not see those modifications. This
is good because current tests assume that input data is never modified,
however this could be an incorrect assumption if some test does not
behave properly.
The benefit of doing this is that we can now handle directories that
contain symlinks and other arbitrary things, such as the static_test_env
required by filesystem tests.
As a fly-by fix, we also accumulate several commands to perform over SSH
and execute them at once instead of SSHing several times. This should be
faster on average.
If a ShTest has for example another command in front of the test
executable it wants to execute, ssh.py needs to properly translate
the path of that test executable to the executable on the remote host.
For example, running '%{exec} ! %t.exe', we can't assume that the
test-executable is the first argument after '%{exec}'.
This makes it closer to how one would run the tests by hand, and it is
also closer to how the SSHExecutor runs the tests remotely. It also
allows using shell builtins in .sh.cpp tests when using %{exec}.
That way, local lit configuration files don't have to worry about
deep-copying the compiler instance of the test format, which is
arguably an implementation detail.
We pass the config to this method even though it is not used by the
current test format because this allows replacing the current test
format by other test formats that would require the config to add
new compile flags.
This reduces the complexity of our already complex global lit configuration,
and also avoids cluttering the compilation commands for all tests with
things that are only relevant to the filesystem tests.
Differential Revision: https://reviews.llvm.org/D76785
Previously, filesystem tests would require LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT
to be present in the environment and to match the value provided when
compiling, as a macro. This has the problem that it only allows for the
filesystem tests to be run on the same machine they are created.
Instead, we create a temporary directory for each test. Technically,
this is tricky to do because we're relying on some of the code that
we're testing to do this. However, there's no other portable way of
creating temporary direcories in C++, so this is difficult to avoid.
Differential Revision: https://reviews.llvm.org/D76731
This re-commits cd7f9751c3, which was reverted in 12f6b024f9 because
it broke the LLVM `check-all` target. This commit addresses the underlying
issue by not setting the lit_config.recursiveExpansionLimit parameter of
the libc++ test suite, which is otherwise picked up by other test suites
in LLVM.
Once we've settled on a fix for the underlying issue with
lit_config.recursiveExpansionLimit, we can start using it
again in libc++, but for now we can just work around it.
This allows adding compilation flags for a single test, which can help
eliminate some .sh.cpp tests and some custom handling in the libc++
test format.
It also works around the issue that .sh.cpp substitutions are _not_
equivalent to the actual compiler command lines used to compile tests,
since the compiler flags can be modified in local lit configurations,
and substitutions are frozen at that point. For example using %{compile}
in a .sh.cpp test in the coroutines subdirectory will not include the
-fcoroutines-ts flag, which is added in the local lit config, because
the %{compile} substitution is created long before we add -fcoroutines-ts
to the compiler flags (in the lit.local.cfg for coroutines).
This reverts commit cd7f9751c3 which has
unintended breakage to non-libcxx projects when using the documented way
of building LLVM. (See the Getting Started guide. I.e. one big CMake setup.)
Since lit supports expanding substitutions recursively, we can define
substitutions in terms of other substitutions. This allows us to simplify
how libc++ substitutions are defined.
This doesn't change the substitutions at all, it only makes them simpler
to define.
lit is not very clever when it performs substitution on RUN lines. It
simply looks for a match anywhere in the line (without tokenization)
and replaces it by the expansion. This means that a RUN line containing
e.g. `-verify-ignore-unexpected=note` wouod be expanded to
`-verify-ignore-unexpected=<substitution for not>e`, which is
surprising and nonsensical.
It also means that something like `%compile_module` could be expanded
to `<substitution-for-%compile>_module` or to the correct substitution,
depending on the order in which substitutions are evaluated by lit.
To avoid such problems, it is a good habit to delimit custom substitutions
with some token. This commit does that for all substitutions used in the
libc++ and libc++abi test suites.
Summary:
The gdb pretty printer misprints variables declared via
using declarations of the form:
namespace foo {
using string_view = std::string_view;
string_view bar;
}
This change fixes that, by deferring the decision to ignore
types not inside std until after desugaring.
Reviewers: #libc!
Subscribers: broadwaylamb, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D76816
This reverts commit a32b94c6c3.
The buildbot startup scripts need to run as root. The buildbot
worker should have already been running as a different account.
More investigation needed.
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
It's hard to imagine someone using a recent version of libc++ with a
roughly 3 years old Clang. Since we're not testing libc++ with Clang 3.5
anyway, claiming support for it is somewhat of a lie.
Note that we don't test Clang 4 either, however I have no reason to bump
the requirement beyond Clang 4 at the moment, whereas removing Clang 3.5
allows simplifying the test suite.
Differential Revision: https://reviews.llvm.org/D76618
This commit rewrites/removes the docker files used to create
the libc++ buildbots.
The major changes in this patch are:
1. Delete Dockerfiles used to build compilers. These have moved to
github.com/efcs/compiler-images
2. Minimize the llvm-buildbot docker image. Instead of running the
buildbots from a committed docker image, the builders now build the
image on startup. This means changes to the docker file automatically
propogate to the builders (within ~24 hours without restart).
3. Version the compilers used by the builders. This means the bots
won't start failing because the apt.llvm.org clang package updated.
Before this patch, the %run substitution did not contain the same
environment variables as normal `pass.cpp` tests. It also didn't
have the right working directory and the script wasn't aware of
potential file dependencies.
With this change, the combination of %build and %run in a .sh.cpp script
should match how pass.cpp tests are actually executed much more closely.
Summary: The return type modification has already been implemented in rL364840 and rL365290.
Reviewers: ldionne, mclow.lists, EricWF, #libc!
Reviewed By: ldionne
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D70275
We always want to build the table of contents. Additionally, we also
set the flag to make the output deterministic which is already the
default for llvm-ar.
Differential Revision: https://reviews.llvm.org/D74108
I've been sitting on this change for a while and have been using
it to build the bot images, so it should be upstream.
This re-configures the docker build files to use docker-compose
more heavily. This allows for composing large images with multiple
compilers without invalidating the docker caches.
After this commit I'll quickly switch all the current buildbots
over to a new docker image, followed by another update to add new
compilers
Otherwise, the `availability=XXX` lit feature is set even when we're
testing trunk and _LIBCPP_DISABLE_AVAILABILITY is defined, which causes
tests that check for availability markup to be enabled and unexpectedly
pass.
Summary:
This patch implements https://wg21.link/P0325.
Please mind that at it is my first contribution to libc++, so I may have forgotten to abide to some conventions.
Reviewers: EricWF, mclow.lists, ldionne, lichray
Reviewed By: ldionne, lichray
Subscribers: lichray, dexonsmith, zoecarver, christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D69882
Summary:
This patch adds a new target info object called LinuxRemoteTI.
Unlike LinuxLocalTI, which asks the host system about various things
like available locales, distribution name etc. which don't make sense
if we're testing on a remote board, LinuxRemoteTI uses SSHExecutor
to get information from the target system.
Reviewers: jroelofs, ldionne, bcraig, EricWF, danalbert, mclow.lists
Reviewed By: jroelofs
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D72847
Too many warnings are being disabled too quickly. Warnings are
important to keeping libc++ correct. This patch re-enables two
warnings: -Wconstant-evaluated and -Wdeprecated-copy.
In future, all warnings disabled for the test suite should require
an attached bug. The bug should state the plan for re-enabling that
warning, or a strong case why it should remain disabled.
Summary:
The __name__ attribute is the correct way to get a function name in
Python 3. This also works with Python 2.
Reviewers: jroelofs, EricWF
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71136
target_info is inferred to WindowsLocalTI on Windows hosts unless
specified otherwise. In the latter case, it doesn't make sense to use
Windows-specific settings if the target is not Windows.
This change should not break anything, because target_info is inferred
based on what platform.system() returns. self.is_windows was set based
on the same platform.system() call.
Thanks to Sergej Jaskiewicz for the patch.
Differential Revision: https://reviews.llvm.org/D68275
When running libc++ tests on a remote machine via SSH, we can encounter
a 'Permission denied' error.
Fix this with plain old 'chmod +x <executable>'.
Thanks to Sergej Jaskiewicz for the patch.
Differential Revision: https://reviews.llvm.org/D69170
Summary:
This allows the linker script generation to query CMake properties
(specifically the dependencies of libc++.so) instead of having to
carry these dependencies around manually in global variables. Notice
the removal of the LIBCXX_INTERFACE_LIBRARIES global variable.
Reviewers: phosek, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68343
llvm-svn: 374116
The first commit removed the workaround in a old script.
This patch removes it in the file actually used by the bots.
I have no idea if this is still needed, but removing the
workaround seems like the easiest way to test.
I'll revert this change if the bots go red.
llvm-svn: 373653
I have no idea if this is still needed, but removing the
workaround seems like the easiest way to test.
I'll revert this change if the bots go red.
llvm-svn: 373650
Summary:
I haven't managed a small reproduction for this bug, it involves
complicated and deeply nested data structures with a wide variety
of pretty printers. But in general, we shouldn't be combining
gdb's command line interface (via gdb.execute) with pretty-printers.
Subscribers: christof, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68306
llvm-svn: 373402
Summary:
This patch is an exact duplicate of https://reviews.llvm.org/D65609, except
that it uses the newly introduced testing framework to detect if gdb is present
so that the tests won't fail on machines without gdb.
Reviewers: echristo, EricWF
Subscribers: christof, ldionne, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67238
llvm-svn: 371131
Summary: Also add a test suite.
Reviewers: EricWF
Subscribers: christof, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65609
Run a pep8 formatter.
Run pep8 formatter.
Convert to PEP8, address other comments from code review.
llvm-svn: 370551
Popen.communicate() method in Python 2 returns a pair of strings, and in
Python 3 it returns a pair of byte-like objects unless universal_newlines
is set to True. This led to an error when using Python 3. With this patch,
merge_archives.py works fine with Python 3.
Thanks to Sergej Jaskiewicz for the patch.
Differential Revision: https://reviews.llvm.org/D66649
llvm-svn: 369764
The build should generally be quiet if there are no errors,
and this script has been around long enough that we can remove
the log output. If we ever need to debug something with this script,
we can put back the logging then.
Differential Revision: https://reviews.llvm.org/D66594
llvm-svn: 369757
If the compiler is (for example) AppleClang 10.0.1, we would previously
populate the following lit features:
apple-clang
apple-clang-10
apple-clang-10.0
This patch additionally populates a feature called 'apple-clang-10.0.1',
which allows more precise enabling/disabling of tests.
llvm-svn: 369406
Summary:
Quote the value of environment variables when passing them to the SSH
client in SSHExecutor in libc++'s lit utilities. Without the quotes,
an environment variable like FOO="buzz bar" gets passed incorrectly
like this, ssh env FOO=buzz bar, which causes bar to be treated as a
command to run, not part of the environment variable value.
We ran into this when using SSHExecutor to do bringup of our CUDA
libcu++ port on an embedded aarch64 system.
Patch by Bryce Adelstein Lelbach.
Differential Revision: https://reviews.llvm.org/D65960
llvm-svn: 368317
This commit adds a __pstl_config_site header that contains the value of
macros specified at CMake configuration time. It works similarly to
libc++'s __config_site header, except we always include it as a separate
file instead of concatenating it to the main configuration header.
It is necessary to thread the includes for that header into libc++'s
lit configuration, otherwise we'd be requiring an installation step
prior to running the test suite.
llvm-svn: 368284
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
The first attempt to commit this failed because it exposed a bug in the
tests for modules. Now that this has been fixed, it should be safe to
commit this.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 367903
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
llvm-svn: 367770
The test configuration contained a bug where we only raised
the __config_site commands to the command line if modules were
enabled for all of the libc++ tests. However there are special
modules-only tests, and these tests weren't getting the correct
defines.
This patch corrects that issue.
llvm-svn: 367267
Summary:
On AIX psutil can run into problems with permissions to read the process
tree, which causes problems for python timeout tests which need to kill off
a test and it's children.
This patch adds a workaround by invoking shell via subprocess and using a
platform specific option to ps to list all the descendant processes so we can
kill them. We add some checks so lit can tell whether timeout tests are
supported with out exposing whether we are utilizing the psutil
implementation or the alternative.
Reviewers: hubert.reinterpretcast, andusy, davide, delcypher
Reviewed By: delcypher
Subscribers: davide, delcypher, christof, lldb-commits, libcxx-commits, llvm-commits
Tags: #lldb, #libc, #llvm
Differential Revision: https://reviews.llvm.org/D64251
llvm-svn: 366912
This is a cherrypick of D64237 onto llvm/utils/benchmark and
libcxx/utils/google-benchmark.
Differential Revision: https://reviews.llvm.org/D65142
llvm-svn: 366868
libc++'s lit configuration infers the C++ language dialect when it is
not provided by checking which -std= flags that a compiler supports.
GCC 5 and GCC 6 have a -std=c++17 flag, however, they do not have full
C++17 support. The lit configuration has hardcoded logic that removes
-std=c++1z as an option to test for GCC < 7, but not -std=c++17.
This leads to a bunch of failures when running libc++ tests with GCC 5
or GCC 6. This patch adds -std=c++17 to the list of flags that are
discarded for GCC < 7 by lit's language dialect inference.
Thanks to Bryce Adelstein Lelbach for the patch.
Differential Revision: https://reviews.llvm.org/D62874
llvm-svn: 366700
This reverts r366593, which caused unforeseen breakage on the build bots.
I'm reverting until the problems have been figured out and fixed.
llvm-svn: 366603
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
Reviewers: rodgert, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 366593
Use binary mode to read test files in libcxx LibcxxTestFormat class.
This ensures that tests are read correctly independently of encoding,
and therefore fixes UnicodeDecodeError when file is opened in Python 3
that defaults to pure ASCII encoding.
Technically this could be also fixed via conditionally appending
encoding argument when opening the file in Python 3. However, since
the code in question only searches for fixed ASCII substrings reading
it in binary mode is simpler and more universal.
Differential Revision: https://reviews.llvm.org/D63346
llvm-svn: 364170
ar doesn't produce the correct results when used for linking static
archives on Apple platforms, so instead use libtool -static which is
the official way to build static archives on those platforms.
Differential Revision: https://reviews.llvm.org/D62770
llvm-svn: 362311
Summary:
This provides the `std::destroying_delete_t` declaration in C++2a and after. (Even when the compiler doesn't support the language feature).
However, the feature test macro `__cpp_lib_destroying_delete` is only defined when we have both language support and C++2a.
Reviewers: ldionne, ckennelly, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: dexonsmith, riccibruno, christof, jwakely, jdoerfert, mclow.lists, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D55840
llvm-svn: 361572
This addresses the issue introduced in D60309 which leads to linker
scripts being generated with absolute paths.
Differential Revision: https://reviews.llvm.org/D61039
llvm-svn: 359045
This enables the use of this script from other build systems like
GN which don't support post-build actions as well as for static
archives.
Differential Revision: https://reviews.llvm.org/D60309
llvm-svn: 358915
Summary:
Ensure we re-export __cxa_throw_bad_array_new_length and
__cxa_uncaught_exceptions from libc++, since they are now
provided by libc++abi.
Doing this allows us to stop linking explicitly against libc++abi in
the libc++abi tests, since libc++ re-exports all the necessary symbols.
However, there is one caveat to that. We don't want libc++ to re-export
__cxa_uncaught_exception (the singular form), since it's only provided
for backwards compatibility. Hence, for the single test where we check
this backwards compatibility, we explicitly link against libc++abi.
PR27405
PR22654
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60424
llvm-svn: 358690
Summary:
Otherwise, it doesn't take into account things like whether the symbol
is defined or undefined, and whether symbols are indirect references
(re-exports) or not.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60416
llvm-svn: 358408
We used to do it against the current system's libc++abi, which is not as
good as doing it with the libc++abi that matches the libc++ we're running
against.
Note that I made sure we were indeed picking up the provided libc++abi
by replacing it by something that doesn't work and watching it burn.
llvm-svn: 358294
Dylib support for shared_mutex was added in macOS 10.12, so the tests
should be XFAILed accordingly instead of being completely disabled
whenever availability is enabled.
rdar://problem/48769104
llvm-svn: 357079
Summary:
I can't see a good reason to disallow this, even though it isn't the
standard way we build libc++ for Apple platforms.
Making this work on Apple platforms requires using different flags for
--whole-archive and removing the -D flag when running `ar` to merge
archives because that flag isn't supported by the `ar` shipped on Apple
platforms. This shouldn't be an issue since the -D option appears to be
enabled by default in GNU `ar`.
Reviewers: phosek, EricWF, serge-sans-paille
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59513
llvm-svn: 356903
Summary: Filesystem doesn't work on Windows, so we need a mechanism to turn it off for the time being.
Reviewers: ldionne, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: mstorsjo, mgorny, christof, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59619
llvm-svn: 356633
This fixes CI for back-deployment testers on platforms that don't have
<filesystem> support in the dylib.
This is effectively half of https://reviews.llvm.org/D59224. The other
half requires fixes in Clang.
llvm-svn: 356558
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.
Unlike the previous attempt (r356500), this doesn't remove all the
filesystem tests.
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: 356518
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
Otherwise, when testing trunk libc++ on an older system, lit will think
that the dylib features are disabled. Ideally, we'd have a notion of
running the tests with/without a deployment target (or, equivalently,
a deployment target representing trunk where everything is as recent
as can be). Since we always have a deployment target right now (which
defaults to the current system), we only enable those features when
we're going to also be testing with the system libc++.
We also need to disable the availability markup when we are not running
a system library flavor, because availability markup does not make sense
when building against the trunk libc++ (which has everything regardless
of what the current system is).
This is a re-application of r353319, which had been reverted due to
CI breakage. This time around, I made sure it didn't break our internal
CI before submitting.
This is also a partial undoing of r348296, in spirit at least. However,
with this patch, availability markup is enabled based on whether we're
using a system library or not, whereas previously one could enable
it or disable it arbitrarily. This was confusing as it led to testing
configurations that don't make sense (such as testing a system library
without availability markup, or trunk testing with availability markup).
llvm-svn: 355451
Summary:
This patch fixes a lifetime bug when inserting a new container into the debug database. It is
diagnosed by UBSAN when debug mode is enabled. This patch corrects how nodes are constructed
during insertion.
The fix requires unconditionally breaking the debug mode ABI. Users should not expect ABI
stability from debug mode.
Reviewers: ldionne, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: mclow.lists, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D58011
llvm-svn: 355367
LLVM is dropping support for GCC 4.9. This patch adds
a GCC 5 installation to the buildbot image so we can upgrade
the 4.9 bot to GCC 5.
As a temporary workaround until zorg updates, we install GCC 5
as GCC 4.9.
llvm-svn: 355334
glob can return files in arbitrary order which breaks deterministic
builds. Rather, use `ar t` to list the files in each archive and
preserve the original order. Using `ar q` results in duplicate entries
in the archive, instead use `ar r` to avoid duplicates.
Differential Revision: https://reviews.llvm.org/D58024
llvm-svn: 353671
Different versions of python print dictionaries in different orders.
This can mess up diffs when updating ABI lists. This patch uses
pprint.pformat to print the dicts to get a consistent ordering.
llvm-svn: 353634
The test configuration support currently searches for libc++ sources
in <ROOT>/projects/libcxx. This change also additionally searches
<ROOT>/runtimes/libcxx (so called runtimes layout) and <ROOT>/libcxx
(monorepo layout).
This matches the logic we already use in CMake, for example:
https://github.com/llvm/llvm-project/blob/6fd4e7f/libcxx/CMakeLists.txt#L148
When the monorepo becomes the only supported layout in the future,
we can simplify this logic again.
Differential Revision: https://reviews.llvm.org/D57776
llvm-svn: 353600
Otherwise, when testing trunk libc++ on an older system, lit will think
that the dylib features are disabled. Ideally, we'd have a notion of
running the tests with/without a deployment target (or, equivalently,
a deployment target representing trunk where everything is as recent
as can be). Since we always have a deployment target right now (which
defaults to the current system), we only enable those features when
we're going to also be testing with the system libc++.
llvm-svn: 353319
We're building tests with -nostdlib which means that we need to
explicitly include the builtins library. When using libgcc (default)
we can simply include -lgcc_s on the link line, but when using
compiler-rt builtins we need a complete path to the builtins library.
This path is already available in CMake as <PROJECT>_BUILTINS_LIBRARY,
so we just need to pass that path to lit and if config.compiler_rt is
true, link it to the test.
Prior to this patch, running tests when compiler-rt is being used as
the builtins library was broken as all tests would fail to link, but
with this change running tests when compiler-rt bultins library is
being used should be supported.
Differential Revision: https://reviews.llvm.org/D56701
llvm-svn: 353208
This patch removes some vendor-specific availability XFAILs from the
test suite. In the future, when a new feature is introduced in the
dylib, an availability macro should be created and a matching lit
feature should be created. That way, the test suite can XFAIL whenever
the implementation lacks the necessary feature instead of being
cluttered by vendor-specific annotations.
Right now, those vendor-specific annotations are still somewhat cluttering
the test suite by being in `config.py`, but at least they are localized.
In the future, we could design a way to define those less intrusively or
even automatically based on the availability macros that already exist
in <__config>.
llvm-svn: 353201
There are several changes:
- Don't stringify Pythonized bools (that's why we're Pythonizing them)
- Support specifying target and sysroot via CMake variables
- Use consistent spelling for --target, --sysroot, --gcc-toolchain
llvm-svn: 353137
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
to reflect the new license.
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: 351636
This script can be used by CI systems to test things like availability
markup and binary compatibility on older MacOS versions. This is still
a bit rough on the edges, for example we don't test libc++abi yet.
llvm-svn: 350752
Summary:
Tests marked with the flaky attribute ("FLAKY_TEST.")
can still report false positives in local tests and on the
NetBSD buildbot.
Additionally a number of tests (probably all threaded
ones) unmarked with the flaky attribute is flaky on
NetBSD.
An ideal solution on the libcxx side would be to raise
max retries for NetBSD and mark failing tests with
the flaky flag, however this adds more maintenance
burden and constant monitoring of flaky tests.
Reduce the work and handle flaky tests as more flaky
on NetBSD and allow flakiness of other tests on
NetBSD.
Reviewers: mgorny, EricWF
Reviewed By: mgorny
Subscribers: christof, llvm-commits, libcxx-commits
Differential Revision: https://reviews.llvm.org/D56064
llvm-svn: 350170
Add a target_info definition for NetBSD. The definition is based
on the one used by FreeBSD, with libcxxrt replaced by libc++abi,
and using llvm-libunwind since we need to use its unwinder
implementation to build anyway.
Additionally, XFAIL the 30 tests that fail because of non-implemented
locale features. According to the manual, NetBSD implements only
LC_CTYPE part of locale handling. However, there is a locale database
in the system and locale specifications are validated against it,
so it makes sense to list the common locales as supported.
If I'm counting correctly, this change enables additional 43 passing
tests.
Differential Revision: https://reviews.llvm.org/D55767
llvm-svn: 349379
Otherwise, even specifying a runtime root different from the library
we're linking against won't work -- the library we're linking against
is always used. This is undesirable if we try testing something like
linking against a recent libc++.dylib but running the tests against an
older version (the back-deployment use case).
llvm-svn: 349171
Other standard libraries don't implement availability markup, so it doesn't
make sense to e.g. XFAIL tests based on availability markup outside of
libc++.
llvm-svn: 348871
This is part of an ongoing cleanup of the LIT test suite, where I'm
trying to reduce the number of configuration options. In this case,
the original intent seemed to be running the test suite with libstdc++,
but this is now supported by specifying cxx_stdlib_under_test=libstdc++.
llvm-svn: 348868
It is unreachable because we test that the cxx_stdlib_under_test is
in the supported set of libraries elsewhere. Furthermore, this code
relied on the `use_stdlib_type`, which is never defined.
llvm-svn: 348867
Otherwise, some tests would fail when a relative path was passed,
because they'd use the relative path from a different directory
than the current working directory.
llvm-svn: 348525
Summary:
Running the tests without availability enabled doesn't really make sense:
availability annotations allow catching errors at compile-time instead
of link-time. Running the tests without availability enabled allows
confirming that a test breaks at link-time under some configuration,
but it is more useful to instead check that it should fail at compile-time.
Always enabling availability in the lit test suite will greatly simplify
XFAILs and troubleshooting of failing tests, which is currently a giant
pain because we have these two levels of possible failure: link-time and
compile-time.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D55079
llvm-svn: 348296
We used to print a Python list corresponding to the command. It is more
useful to print the joined string so it can be copy/pasted directly when
a test fails.
llvm-svn: 347471
Louis Dionne