When running on remote hosts, we need the whole `echo 123 | %t.exe` command
to run on the remote host. Thus, we need to escape the pipe to make sure
the command is treated as `{ echo 123 | %t.exe } > %t.out` instead of
`{ echo 123 } | %t.exe > %t.out`m where only `echo 123` is run on the
remote host.
Running `export` when there is no environment variable to export will
cause the environment on the remote host to be printed. We don't want
that, so don't run any `export` command on the host when there's no env.
Since c0cd106fcc, we add __config_site macro defines to the compiler
command line whether we are building with modules or not. This means
that the modules tests are expected to fail on single-threaded systems
whether we build with modules or not.
Summary:
Instead of storing `static_test_env` (with all the symlinks) in the repo, we create it on the fly to be cross-toolchain-friendly. The primary use case for this are Windows-hosted cross-toolchains. Windows doesn't really have a concept of symlinks. So, when the monorepo is cloned, those symlinks turn to ordinary text files. Previously, if we cross-compiled libc++ for some symlink-friendly system (e. g. Linux) and ran tests on the target system, some tests would fail. This patch makes them pass.
Reviewers: ldionne, #libc
Reviewed By: ldionne, #libc
Subscribers: EricWF, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D78200
Instead of storing static_test_env (with all the symlinks) in the repo,
we create it on the fly to be cross-toolchain-friendly. The primary
use case for this are Windows-hosted cross-toolchains. Windows doesn't
really have a concept of symlinks. So, when the monorepo is cloned,
those symlinks turn to ordinary text files. Previously, if we
cross-compiled libc++ for some symlink-friendly system (e. g. Linux) and
ran tests on the target system, some tests would fail. This patch makes
them pass.
Differential Revision: https://reviews.llvm.org/D78200
This commit removes minor features of the test suite that I've never
seen used and that are basically just a maintenance burden:
- color_diagnostics: Diagnostics are colored by default when running
from a terminal, and not colored otherwise. This is the right behavior.
Being able to tweak this has minor value, and could be achieved by
modifying the %{compile_flags} instead if absolutely needed.
- ccache: This can be achieved by using a wrapper for the %{cxx}
substitution.
- _dump_macros_verbose is just a dead function now.
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 tests were disabled under ASAN/MSAN because old Clangs were very
slow to build the test cases. However, I checked with the Clang used
on our build bots and the tests are not slow to build anymore, so the
tests can be re-enabled.
Android doesn't have a libgcc_s and uses libgcc instead, so adjust the
build accordingly. This matches compiler-rt's build setup. libc++abi and
libunwind were already checking for libgcc but in a different context.
This change makes them search only for libgcc on Android now, but the
code to link against libgcc if it were present was already there.
Reviewed By: #libc, #libc_abi, #libunwind, rprichard, srhines
Differential Revision: https://reviews.llvm.org/D78787
Summary:
pr42199
When using regex_constants::match_prev_avail, it is defined that
--first is valid, and match_not_bol and match_not_bow should be
ignored. At the moment these flags are not ignored. This fixis that.
Reviewers: ldionne, miyuki, EricWF, mclow.lists, #libc
Reviewed By: ldionne, miyuki, #libc
Subscribers: broadwaylamb, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75622
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.
On Windows, quoting with single-quotes is both unnecessary and incorrect.
If the arguments are properly handled by Lit (which they are), quoting
should not be necessary.
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.
Instead of completely disabling the tests on Apple, which makes them
disabled on all platforms we test (and hence useless), this commit
disables only the assertions that actually fail. I also created a
bug report to track re-enabling them (https://llvm.org/PR45739).
These two locale tests are disabled because they were said to "pass in
an uncontrolled manner on Apple platforms". This commit re-enables them
to see what that means, and whether that is still relevant on the
platforms we test.
Before this commit, the tests were either XFAILed or UNSUPPORTED on
Apple and Linux, which is pretty much all the systems we support. If
the tests truly don't work anywhere, they should be removed instead.
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
This relands this commit as it broke the LLDB bot the first time it landed.
See also the discussion on https://reviews.llvm.org/rG82b47b2978405f802a33b00d046e6f18ef6a47be
Since D74892 this code should now also work on macOS.
Original description:
libc++ is careful to not fracture overload sets. When one overload
is visible to a user, all of them should be. Anything less causes
subtle bugs and ODR violations.
Previously, in order to support ::abs and ::div being supplied by
both <cmath> and <cstdlib> we had to do awful things that make
<math.h> and <stdlib.h> have header cycles and be non-modular.
This really breaks with modules.
Specifically the problem was that in C++ ::abs introduces overloads
for floating point numbers, these overloads forward to ::fabs,
which are defined in math.h. Therefore ::abs needed to be in math.h
too. But this required stdlib.h to include math.h and math.h to
include stdlib.h.
To avoid these problems the definitions have been moved to stddef.h
(which math includes), and the floating point overloads of ::abs
have been changed to call __builtin_fabs, which both Clang and GCC
support.
Defining the nested types `reference` and `iterator_concept` of `reverse_iterator<I>` necessarily requires `I` to be complete in C++20. These tests that verify that `std::map<int, X>::reverse_iterator` can be instantiated when `X` is incomplete are going to have a bad time.
Differential Revision: https://reviews.llvm.org/D78944
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
The runtime for Blocks may not be available even though the Blocks
language extension _is_ available. Instead of potentially failing,
this commit is much more conservative and assumes the runtime for
Blocks is only provided on Apple platforms.
Differential Revision: https://reviews.llvm.org/D78757
The introduction of LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT changed
the default from =1 (assuming merged typeinfos) to =0 (not assuming
merged typeinfos) on all platforms where at least one other __config_site
macro is defined.
This commit explicitly enables the assumption of merged typeinfo names
on Apple platform to restore the previous behavior, at least until the
underlying issue has been fixed.
Instead of the ad-hoc #define _LIBCXX_DYNAMIC_FALLBACK, provide an option
to enable the setting when building libc++abi. Also use the occasion to
rename the option to something slightly more descriptive.
Note that in the future, it would be great to simply remove this option
altogether. However, in the meantime, it seems better to have it be an
official option than something ad-hoc.
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
It turns out that all this time, we've actually been building without
assertions enabled in the dylib. This commit updates the Apple CMake
cache to make it consistent with reality.
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
Summary:
When I read this on the website it looks like the `--` in the used font turns
into an em dash. I updated this with inline literal mark up so the `--` will
remain obvious.
Reviewers: EricWF, #libc!
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D78405
We previously tried re-exporting symbols that didn't exist when
exceptions were disabled. Note that building libc++abi without
exceptions still doesn't work when linking against the default-provided
libSystem.dylib, because it transitively depends on libobjc.dylib,
and that requires __gxx_personality_v0. But building libc++abi
with exceptions and libc++ without exceptions does work.
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.
Marked unsupported for C++03 and C++11 since this test uses alias
declarations, and at least one C++03 bot was failing with
-Wc++11-extensions.
Change-Id: I8c3a579edd7eb83e0bc74e85d116b68f22400161
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.
When running the tests through `lit` directly instead of through `check-cxx`,
it is required to manually build the `cxx` (and often `cxx_experimental`)
targets. Instead of having to do that manually, this commit adds a new
target `check-cxx-deps` that does that for you.
When building these tests without modules in the whole test suite,
the __config_site macro definitions are not included anymore in the
%{compile_flags}. This causes the _LIBCPP_HAS_NO_THREADS define not
to be picked up, and the test to XPASS on single-threaded systems.
This is a stop-gap measure to fix the build bots, however the proper
solution would be to always pass the __config_site defines as compiler
macros, whether we build with modules or not.
Avoid using <sys/types.h> in those tests so that we can run them on
non-AIX systems (otherwise this test is basically dead-code on all
the build bots I'm aware of). Also, split up the test to allow using
.compile.pass.cpp tests instead of .sh.cpp tests, since that is the
last test referencing the %{compile} substitution explicitly.
Instead of being ShTests that use clang-verify (and without the proper
REQUIRES annotation), create .verify.cpp tests instead with the right
REQUIRES annotation.
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
Summary: We discovered that the compiler may chose not to inline the operator=, which leads to an expensive extra stack frame. This change makes __assign_no_alias always tail called.
Reviewers: EricWF, #libc!
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D77913
The libc++ test suite has a lot of old Lit features used to XFAIL tests
and mark them as UNSUPPORTED. Many of them are to workaround problems on
old compilers or old platforms. As time goes by, it is good to go and
clean those up to simplify the configuration of the test suite, and also
to reflect the testing reality. It's not useful to have markup that gives
the impression that e.g. clang-3.3 is supported, when we don't really
test on it anymore (and hence several new tests probably don't have the
necessary markup on them).
The use of the `&& ...` fold expression in std::array's deduction guides
recursively builds a set of binary operator expressions of depth N where
`N` is the number of elements in the initializer.
This is problematic because arrays may be large, and instantiation
depth is limited.
This patch addresses the issue by flattening the SFINAE using
the existing `__all` type trait.
Patch from Christopher Di Bella (cjdb@google.com)
Reviewed as https://reviews.llvm.org/D74291
Adds `std::same_as` to libc++. Since there aren't clang-format rules for
//requires-expressions//, I'll need to disable the formatter in certain areas.
Our documentation for running LIT is basically wrong, since it doesn't
mention `llvm-lit`, and nothing works without it. Note that this
documentation improvement reflects the current reality outside of
the recent efforts on improving the test suite. My goal is to document
the current way of running the test suite, so that everybody agrees on
how things currently work. As the configuration system for libc++ gets
simplified, we can come back and keep this documentation up to date to
reflect those changes.
Differential Revision: https://reviews.llvm.org/D77673
Summary: 5ade17e broke __is_pointer for Objective-C pointer types. This patch fixes the builtin and re-applies the change to type_traits.
Tags: #clang, #libc
Differential Revision: https://reviews.llvm.org/D77519
std::optional requires C++17. Instead of only running the test above
C++14, this commit removes uses of std::optional from the test (it's
already tested in block.objc.pass.mm).
Broke builders that emit different diagnostics. e.g.:
error: 'warning' diagnostics seen but not expected:
Line 13: alias declarations are a C++11 extension
Line 20: alias declarations are a C++11 extension
This reverts commit ff87813715.
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.
Otherwise, files don't link when using a GNU linker, which is more
sensitive on the order of the source file relative to the various
linked libraries. See http://c-faq.com/lib/libsearch.html for an
explanation of the problem.
Both test formats are equivalent, so this *should* not be a problem.
We've fixed a couple of failures uncovered by the first time we tried
making the switch, so this new attempt should go even farther.
If failures are noticed, it should be fine to revert this commit, but
please give a heads up afterwards so we know to address the issues!
Also note that it is still possible to use the old format by passing
`--param=use_old_format=True` when running Lit for the time being.
Summary:
This is a patch that Android has been carrying in its tree for several
years. This patch upstreams the existing ABI.
There's some historical cruft here. __regex_word used to be a part of
regex_traits rather than ctype_base. Bionic also used to use its own
ctype implementation because the libc++ builtin one wasn't available
yet. Bionic's ctype masks were 8 bits wide and already saturated, so a
wider type needed to be used for the regex mask, and the existing
value was already used so Android needed to specify its own.
Since then Android has migrated to the builtin ctype implementation
and this patch probably should have been dropped then. Unfortunately
that was not noticed at the time, so now we need to keep this to
maintain the current ABI.
Reviewers: EricWF, #libc, ldionne
Reviewed By: #libc, ldionne
Subscribers: dexonsmith, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D76171
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 reverts commit 1580c76c4a.
This causes libcxx/selftest/newformat/sh.cpp/substitutions.sh.cpp to
fail with a linker error on Fedora 31 (x86-64) release (no assert)
builds.
Both test formats are equivalent, so this *should* not be a problem.
However, I'm taking advantage of the week-end to test this and see if
there are any failures. If so, it should be fine to revert this until
the failures have been addressed.
For the time being, it is still possible to use the old format by passing
`--param=use_old_format=True` when running Lit.
Summary:
Allow users to simultaneously enable address and undefined behavior
sanitizers, in the same manner that LLVM's 'HandleLLVMOptions.cmake'
allows.
Prior to this patch, `cmake -DLLVM_USE_SANITIZER="Address;Undefined"`
would succeed and the build would build most of the LLVM project with
`-fsanitize=address,undefined`, but a warning would be printed by
libcxx's CMake, and the build would use neither sanitizer. This
patch results in no warning being printed, and both sanitizers are used
in building libcxx.
Reviewers: jroelofs, EricWF, ldionne, #libc!
Subscribers: mgorny, dexonsmith, llvm-commits, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D77466
Always depend on the compiler to have a correct implementation of
max_align_t in stddef.h and don't provide a fallback. For pre-C++11,
require __STDCPP_NEW_ALIGNMENT__ in <new> as provided by clang in all
standard modes. Adjust test cases to avoid testing or using max_align_t
in pre-C++11 mode and also to better deal with alignof(max_align_t)>16.
Document requirements of the alignment tests around natural alignment of
power-of-two-sized types.
Differential revision: https://reviews.llvm.org/D73245
The testing script used to test libc++ historically did not like directories
without any testing files, so these tests had been added. Since this is
not necessary anymore, we can now remove these files. This has the benefit
that the total number of tests reflects the real number of tests more
closely, and we also skip some unnecessary work (especially relevant when
running tests over SSH).
However, some nothing_to_do.pass.cpp tests actually serve the purpose of
documenting that an area of the Standard doesn't need to be tested, or is
tested elsewhere. These files are not removed by this commit.
Removal done with:
import os
import itertools
for (dirpath, dirnames, filenames) in itertools.chain(os.walk('./libcxx/test'),
os.walk('./libcxxabi/test')):
if len(filenames + dirnames) > 1 and \
any(p == 'nothing_to_do.pass.cpp' for p in filenames):
os.remove(os.path.join(dirpath, 'nothing_to_do.pass.cpp'))
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
This test regressed with 5ade17e0ca, but we never noticed it because
.pass.mm tests were skipped due to a bug in our Lit config. This commit
fixes is_pointer (by essentially reverting tha part of 5ade17e0ca) and
also adds .pass.mm tests to the list of supported test suffixes.
We can explore how to support __is_pointer with Objective-C++ qualifiers
as a follow-up -- the main goal of this commit is to fix the regression
quickly and make sure all tests of the suite are run.
Instead of hardcoding absolute paths on the build-host in the executables,
use relative paths from the current working directory. Also, use
FILE_DEPENDENCIES to mark the static test env as being required by
the relevant tests.
Given a SSH executor that copies the files to the remote host properly,
the tests can be run on that remote host.
Chromium's build sets LIBCXX_CXX_ABI_SYSTEM explicitly when building
libc++, which was broken by 61e89737c5 (which stopped listening to
that option). As a workaround, this commit uses the system libc++abi
when LIBCXX_CXX_ABI_SYSTEM is used.
However, we will need to work with Chromium to standardize their build
of libc++, because LIBCXX_CXX_ABI_SYSTEM is not a public facing build
configuration for libc++, and has never been AFAICT.
The 'runtimes' build started failing because libc++ stopped using the
in-tree libc++abi when HAVE_CXXABI is set after 61e89737c. This commit
tries to bring back the old behavior when HAVE_CXXABI is set in order
to fix CIs.
However, we really need to sit down and discuss what ways of building
libc++ are supported and formalize them, because having the libc++ build
system branch on basically random variables in some CMake cache somewhere
is not a viable path forward.
... in `msvc_stdlib_force_include.h` to also ignore new MSVC warning C5215 "'%s' a function parameter with volatile qualified type is deprecated in C++20". Since we're touching it, also update from non-standard `__pragma(meow)` to standard `_Pragma("meow")`.
This patch reimplements the dynamic filesystem helper using Posix
functionality instead of relying on Python. The primary reason for
doing this is that it allows running the libc++ test suite on devices
that do not have Python.
Differential Revision: https://reviews.llvm.org/D77140
In standalone builds the cxxabi_shared and cxxabi_static targets don't exist.
We need to link against the library itself.
Differential Revision: https://reviews.llvm.org/D77294
This commit removes support for building against the system libc++abi,
which was supported on Apple platforms. This is basically never what we
want to do, since libc++ and libc++abi are coupled and building a trunk
libc++ against an older libc++abi can lead to incompatibilities (and
good luck debugging them!). It might have made some sense to support
that when the monorepo did not exist, however I don't think this is
anything but a footgun nowadays.
Furthermore, based on the newly-made assumption that we're building
against the monorepo libc++abi, we can simplify the search path logic
for finding libc++abi.
This area of our build system has a lot of technical debt accumulated,
and it's surprisingly difficult to change. We've tried different things
and failed several times in the past. I did test this change on our
Docker image for the build bots and on Apple platforms, however it is
possible that this breaks some unknown configuration, in which case it
should be fine to revert this (so we can try again!).
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.
Based on an issue brought up in https://reviews.llvm.org/D67900, this commit reverts the changes to is_floating_point and is_arithmetic made in D67900.
After D67900 landed, __float128 behaved differently in those two type traits, causing compiler errors in numeric limits (and possibly others).
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}'.
Using the ADDITIONAL_COMPILE_FLAGS annotation, it is possible to move
these tests from .sh.cpp to .pass.cpp, making them suitable for running
on remote hosts more easily.
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}.
Based on the current discussion in https://llvm.org/PR45307, it seems
that it's legitimate for `temp_directory_path()` to return a path with
a trailing slash. Since `p.parent_path()` will never contain a trailing
slash, comparing it to the result of `temp_directory_path()` will fail
depending on whether `temp_directory_path()` returns a trailing slash
or not.
Otherwise, trying to reproduce a failing filesystem test by copy-pasting
the command-line used and running that in the shell won't work, because
the shell will eat quoting around the define and we'll end up with a
non-stringized path in the .cpp file.
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.
We will soon start removing technical debt and sharing code between the
two directories, so this first step is meant to discover potential places
where the libraries are built outside of a monorepo layout. I imagine
this could happen as a remnant of the pre-monorepo setup.
This was discussed on the libcxx-dev mailing list and we got overall
consensus on the direction. All consumers of libc++ and libc++abi
should already be doing so through the monorepo, however it is
possible that we catch some stragglers with this patch, in which
case it may need to be reverted temporarily.
Differential Revision: https://reviews.llvm.org/D76102
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).
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
This is a re-application of f383fb40b1, wich was reverted in 04d48111b
because the build bots had not been updated yet. The build bot configurations
have now been updated not to use the deprecated targets, and I verified
that they were using the non-deprecated targets, so we should be good
unless I missed a bot.
Differential Revision: https://reviews.llvm.org/D76104
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
We have several test directories whose names end in .spec. Ensure we
don't accidentally ignore them by removing a section of the .gitignore
that's irrelevant for libc++.
Differential Revision: https://reviews.llvm.org/D69195
Introduced by https://reviews.llvm.org/D72687. This condition can happen
when the tests are not being run at all, and we're only trying to generate
the libc++ headers.
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 reverts commit f383fb40b. It looks like several of our build bots
are still using the legacy target names, so we'll change those before
we commit this change again.
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
There's no doubt this commit will break some CI systems, however the
fix is trivial.
Differential Revision: https://reviews.llvm.org/D76104
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.
The current lit test suite doesn't really allow us to express that the
test should be disabled when testing the trunk variant of libc++, even
if we're running it on a supported macOS. Because of that, the test
is enabled when _LIBCPP_DISABLE_AVAILABILITY is defined, and the test
XPASSes.
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.
In C++03 mode, nullptr is defined by libc++, not the compiler so, we can't use __is_fundamental (because it will return false for nullptr).
Fixes: 5ade17e0ca
This patch updates <type_traits> to use builtin type traits whenever
possible to improve compile times.
Differential Revision: https://reviews.llvm.org/D67900
The current implementation of binomial_distribution is not guaranteed to
converge for certain extreme configurations of the engine and distribution.
This is due to a mistake in the implementation of the algorithm from the
given reference paper. The algorithm in the paper is guaranteed to
terminate but has redundant statements. The current implementation
simplified away the redundancy into a while loop, but it excludes the
return condition of the case where a good sample cannot be returned for
the particular sample being used from the uniform distribution, which is
what causes the infinite loop. This change guarantees termination by
recognizing that a good sample cannot be returned and returning 0 after
breaking the loop. This is also in contrast to the paper because the
return value as specified in the paper violates basic checks in at least
a subset of the extreme cases where the current implementation fails to
terminate. This default return value of 0 is satisfactory for the
extreme case known so far.
Since this is only meant to affect extreme cases where the algorithm
does not terminate anyways, the behavior is expected to remain exactly
the same for all non-extreme cases that have been terminating so far.
Fixes https://llvm.org/PR44847
Differential Revision: https://reviews.llvm.org/D74997
Summary:
The former are like:
libcxx/include/typeinfo:322:11: warning: definition of implicit copy constructor for 'bad_cast' is deprecated because it has a user-declared destructor [-Wdeprecated-copy-dtor]
virtual ~bad_cast() _NOEXCEPT;
^
libcxx/include/typeinfo:344:11: note: in implicit copy constructor for 'std::bad_cast' first required here
throw bad_cast();
^
Fix these by adding an explicitly defaulted copy constructor.
The latter are like:
libcxx/include/codecvt:105:37: warning: dynamic exception specifications are deprecated [-Wdeprecated-dynamic-exception-spec]
virtual int do_encoding() const throw();
^~~~~~~
Fix these by using the _NOEXCEPT macro instead.
Reviewers: EricWF, mclow.lists, ldionne, #libc
Reviewed By: EricWF, #libc
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D76150
Summary:
Android's libc uses new/delete internally and these are counted, so
the counter needs to be reset to zero at the start of the test.
Reviewers: EricWF, mclow.lists, #libc, ldionne
Reviewed By: #libc, ldionne
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D76091
The benchmarks are intended to be build with C++17 but the
CMAKE_CXX_STANDARD in the LLVM forces the build to use C++14 by default.
This fixes the issue by setting the CXX_STANDARD property of the benchmark
targets.
The CMake documentation is not clear whether this will use the C++1z
fallback for older compilers. So this may break the benchmarks if somebody
uses the benchmarks with pre C++17 compilers with the C++1z fallback.
Differential Revision: https://reviews.llvm.org/D75955
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
Summary:
This is NFC. We only add additional information to the log.
Reviewers: EricWF, ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: kristof.beyls, dexonsmith, danielkiss, mgorny, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75991
Due to Clang bug http://llvm.org/PR45151, deprecated attributes are not
picked up on partial specializations. This patch instead applies it to
the first declaration of std::function itself.
Summary:
This is a recommit of https://reviews.llvm.org/D73223 where the added function accidentally ended up inside an idef block.
This change splits the copy constructor up inlining short initialization, and explicitly outlining long initialization into __init_copy_ctor_external() which is the externally instantiated slow path.
For unstable ABI, this has the following changes:
remove basic_string(const basic_string&)
remove basic_string(const basic_string&, const Allocator&)
add __init_copy_ctor_external(const value_type*, size_type)
Quick local benchmark for Copy:
Master
```
---------------------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------------------
BM_StringCopy_Empty 3.50 ns 3.51 ns 199326720
BM_StringCopy_Small 3.50 ns 3.51 ns 199510016
BM_StringCopy_Large 15.7 ns 15.7 ns 45230080
BM_StringCopy_Huge 1503 ns 1503 ns 464896
```
With this change
```
---------------------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------------------
BM_StringCopy_Empty 1.99 ns 2.00 ns 356471808
BM_StringCopy_Small 3.29 ns 3.30 ns 203425792
BM_StringCopy_Large 13.3 ns 13.3 ns 52948992
BM_StringCopy_Huge 1472 ns 1472 ns 475136
```
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75639
They need to appear before any member functions are ODR used, because
they change the visibility of many of these functions and otherwise
they could end up with hidden visibility in the DSO.
The goal of the test was only to check that we could access the
`this->current` member of std::reverse_iterator from a derived
class, but in doing so we incremented a null iterator, which is UB.
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
Summary: This review is a mostly trivial change to use an explicit ABI flag for the unstable external template list. This follows the practice for an ABI flag per feature, and provides a spot for the rational / motivation for the flag.
Reviewers: EricWF, ldionne
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75457
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
These tests check that an operations happens within a specified
deadline, which causes flaky failures on slow machines or machines
under heavy load.
By adding the // FLAKY_TEST. tag it allows the test suite to
retry or ignore the tests
The markup wasn't quite right, and that broke compilation with availability
markup enabled. I'm disabling it until I have time to fix it properly to
get the CI mostly green again.
Summary:
This change checks for the case where people want to erase a string to the end, i.e., __n == npos, and inlines the call if so.
This also demonstrates keeping the ABI intact for V1, but inlining the erase() method for unstable.
Reviewers: EricWF, mclow.lists, ldionne
Reviewed By: EricWF, ldionne
Subscribers: smeenai, dexonsmith, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D73743
Summary:
The definition of `__libcpp_timed_backoff_policy` and the declaration of
`__libcpp_thread_poll_with_backoff` must not be guarded by
#if !defined(_LIBCPP_HAS_THREAD_API_EXTERNAL)
because the definitions of `__libcpp_timed_backoff_policy::operator()`
and `__libcpp_thread_poll_with_backoff` aren't guarded by this macro
(and this is correct because these two functions are implemented in
terms of other libc++ functions and don't interact with the host
threading library).
Reviewers: ldionne, __simt__, EricWF, mclow.lists
Reviewed By: ldionne
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75191
Summary:
This change adds the macros _LIBCPP_COMPILER_HAS_BUILTIN_CONSTANT and _LIBCPP_BUILTIN_CONSTANT_P to detect compile time constants, and optimze the code accordingly.
A planned usage example:
The implementation of basic_string::assign() can short-cut a compile time known short string assignent into a fast and compact inlined assignment:
```
basic_string::assign(const value_type* __s) {
if (_LIBCPP_BUILTIN_CONSTANT_P(__s[0]) && length(__s) < __min_cap) {
copy(pointer(), _s, length(__s) + 1);
set_size(length(__s));
} else {
// delegate / tail call out of line implementation
}
}
```
Subscribers: christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D73732
std::shared_ptr::allocate_shared isn't in the standard. This commit removes it from libc++. It updates std::allocate_shared to use __create_with_cntrl_block.
Differential Revision: https://reviews.llvm.org/D66178
It turns out that <semaphore.h> is not well-behaved, as it transitively
includes <sys/param.h>, and that one defines several non-reserved macros
that clash with some downstream projects in modular builds. For the time
being, using <sys/semaphore.h> instead gives us the declarations we need
without the macros.
rdar://59744472
Move the implementation of __libcpp_thread_poll_with_backoff
and __libcpp_timed_backoff_policy::operator() out of the
_LIBCPP_HAS_THREAD_API_PTHREAD block. None of the code in these
methods is pthreads specific.
Also add "inline _LIBCPP_INLINE_VISIBILITY" to
__libcpp_timed_backoff_policy::operator(), to avoid errors due to
multiple definitions of the operator. Contrary to
__libcpp_thread_poll_with_backoff (which is a template function),
this is a normal non-templated method.
Differential Revision: https://reviews.llvm.org/D75102
Summary:
In libc++, we normally #ifdef out header content instead of #erroring
out when the Standard in use is insufficient for the requirements of
the header.
Reviewers: EricWF
Subscribers: jkorous, dexonsmith, libcxx-commits, teemperor
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75074
Depend on the compiler to provide a correct implementation of
max_align_t. If __STDCPP_NEW_ALIGNMENT__ is missing and C++03 mode has
been explicitly enabled, provide a minimal fallback in <new> as
alignment of the largest primitive types.
https://reviews.llvm.org/D68480 added those headers and made the std module
only usable with C++14 or later as the submodules were not marked as requiring
C++14 or later. This just adds the missing requires directives.
- Avoid using C++11-and-later features in <atomic>:
Historically, we've supported <atomic> in C++03, so we can't use C++11
features in that header. This is something we really need to change,
since our implementation of <atomic> is starting to accumulate technical
debt because of that.
- Mark a test as unsupported on single threaded systems
- Add missing symbols to the Linux ABI list
Summary: We want to eventually remove it.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D74719
- Add the new symbols to the ABI list on Darwin
- Add XFAIL markup to the tests that require dylib support on older platforms
- Add availability markup for back-deployment
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.
This change splits the _LIBCPP_STRING_EXTERN_TEMPLATE_LIST up into a _LIBCPP_STRING_V1_EXTERN_TEMPLATE_LIST containing the stable ABI, and a _LIBCPP_STRING_UNSTABLE_EXTERN_TEMPLATE_LIST containing the unstable ABI.
The purpose is to explicitly define and maintain the two lists, where the unstable ABI allows for ABI breaking changes for purposes such as optimization while offering a strong guarantee that any change inside the unstable ABI does not affect the stable ABI.
As per the comment in the __string header, we do still allow etries to be added to the stable ABI list as the c++ versions and corresponding c++ std API changes.
This patch enables throwing exceptions for invalid backreferences
in the constructor when using the basic, extended, grep, or egrep grammar.
This fixes bug 34297.
Differential Revision: https://reviews.llvm.org/D62453
This patch qualifies calls to ref and cref inside ref(reference_wrapper<T>)
and cref(reference_wrapper<T>), respectively. These previously unqualified
calls could break in the presence of user functions called ref/cref inside
associated namespaces: https://gcc.godbolt.org/z/8VfprT
Fixes PR44398.
Differential Revision: https://reviews.llvm.org/D74287
Instead of including <ios> for ios_base::failbit, simply get failbit
member of the template argument. Print directly to a stream instead
of using intermediate ostringstream.
Parsing time: 874ms -> 164ms (-81%)
Thanks to Nikita Kniazev for the patch!
Differential Revision: https://reviews.llvm.org/D71214
The regex backreferences were not properly parsed and used when using
the extended grammar. This change parses them. The issue was found while
working on PR34297.
Thanks to Mark de Wever for the patch!
Differential Revision: https://reviews.llvm.org/D62451
The libc++ __bit_iterator type has weird ABI calling conventions as a
quirk
of the implementation. The const bit iterator is trivial, but the
non-const
bit iterator is not because it declares a user-defined copy constructor.
Changing this now is an ABI break, so this test ensures that each type
is trivial/non-trivial as expected.
The definition of 'non-trivial for the purposes of calls':
A type is considered non-trivial for the purposes of calls if:
* it has a non-trivial copy constructor, move constructor, or
destructor, or
* all of its copy and move constructors are deleted.
This reverts commit 82b47b2978.
This broke Clang and LLDB module builds without -fmodules-local-submodule-visbility.
I'll revert this for now until we have a fix and reland once Clang
can properly handle this code.
See also the discussion in https://reviews.llvm.org/rG82b47b2978405f802a33b00d046e6f18ef6a47be
libc++ is careful to not fracture overload sets. When one overload
is visible to a user, all of them should be. Anything less causes
subtle bugs and ODR violations.
Previously, in order to support ::abs and ::div being supplied by
both <cmath> and <cstdlib> we had to do awful things that make
<math.h> and <stdlib.h> have header cycles and be non-modular.
This really breaks with modules.
Specifically the problem was that in C++ ::abs introduces overloads
for floating point numbers, these overloads forward to ::fabs,
which are defined in math.h. Therefore ::abs needed to be in math.h
too. But this required stdlib.h to include math.h and math.h to
include stdlib.h.
To avoid these problems the definitions have been moved to stddef.h
(which math includes), and the floating point overloads of ::abs
have been changed to call __builtin_fabs, which both Clang and GCC
support.
There are some unnecessary typenames in std/numerics/c.math/abs.pass.cpp;
e.g. they're not in a dependent context.
Patch by Bryce Adelstein Lelbach
Differential Revision: https://reviews.llvm.org/D72106
The static asserts in span<T, N>::front() and span<T, N>::back() are
incorrect as they may be triggered from valid code due to evaluation
of a never taken branch:
span<int, 0> foo;
if (!foo.empty()) {
auto x = foo.front();
}
The problem is that the branch is always evaluated by the compiler,
creating invalid compile errors for span<T, 0>.
Thanks to Michael Schellenberger Costa for the patch.
Differential Revision: https://reviews.llvm.org/D71995
Summary:
In D27429, we switched the Apple implementation of steady_clock::now()
from clock_gettime(CLOCK_MONOTONIC) to clock_gettime(CLOCK_UPTIME_RAW).
The purpose was to get nanosecond precision, and also to improve the
performance of the implementation.
However, it appears that CLOCK_UPTIME_RAW does not satisfy the requirements
of the Standard, since it is not strictly speaking monotonic. Indeed, the
clock does not increment while the system is asleep, which had been
mentioned in D27429 but somehow not addressed.
This patch switches to CLOCK_MONOTONIC_RAW, which is monotonic, increased
during sleep, and also has nanosecond precision.
https://llvm.org/PR44773
Reviewers: bruno, howard.hinnant, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D74341
The calculation _Offset + _Count <= size() may overflow, so use
_Count <= size() - _Offset instead. Note that this is safe due to
the previous constraint that _Offset <= size().
Patch by Michael Schellenberger Costa.
Differential Revision: https://reviews.llvm.org/D71998
Summary:
In `std::filesystem::proximate` tests we assume that the current working directory's name
is `fs.op.proximate`. This is fine when we're running the tests locally.
However, if we're running those tests on a remote machine via SSH, the directory layout may be
different. For example, currently we copy each test executable individually into
a temporary directory on the target board using SCP, so the assumption about the working directory name
doesn't necessarily hold.
This patch is the only thing that is necessary for all libc++ tests to pass when run remotely.
Reviewers: ldionne, EricWF, mclow.lists
Reviewed By: ldionne, EricWF
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D74348
clang 9ce6dc9872 drops support for
implicit conversion of nullptr_t to bool. From that commit:
The C++ rules briefly allowed this, but the rule changed nearly 10
years ago and we never updated our implementation to match. However,
we've warned on this by default for a long time, and no other compiler
accepts (even as an extension).
The system libc++.dylib doesn't support the debug mode, so this test
can't be supported. As a fly-by fix, we also specify more stringently
that only the macOS system library is unsupported in other tests using
the debug mode.
The extent of the returned span was always std::dynamic_extent, which
is incorrect.
Thanks to Michael Schellenberger Costa for the patch.
Differential Revision: https://reviews.llvm.org/D71997
size_t is always greater than 0, so remove the artifact from the old
index_type.
Patch by Michael Schellenberger Costa.
Differential Revision: https://reviews.llvm.org/D71996
Both methods have compile time constraints that we should test against.
Patch by Michael Schellenberger Costa
Differential Revision: https://reviews.llvm.org/D71999
This reverts commit 41f4dfd63e.
It broke standalone libc++ builds, which now try to use libc++abi from the wrong directory, instead of system instance.
(cherry picked from commit 3573526c0286c9461f0459be1a4592b2214594e7)
Summary: This change reflows a comment line. This change serves as a no-op test commit
Reviewers: mclow.lists, ldionne, EricWF
Subscribers: dexonsmith, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D73552
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:
FreeBSD got `timespec_get` support somewhere in the 12.x timeframe, but
the C++ version check in its system headers was written incorrectly.
This has now been fixed for both FreeBSD 13 and 12.
Add checks for the corresponding `__FreeBSD_version` values, to define
`_LIBCPP_HAS_TIMESPEC_GET` when the function is supported.
Reviewers: emaste, EricWF, ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: arichardson, krytarowski, christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71522
This is failing to compile on Windows because clang-cl is trying to
use the path with quotes, dropping them resolves the issue.
Differential Revision: https://reviews.llvm.org/D73525
Configuring libc++abi with LIBCXX_ENABLE_STATIC=OFF is broken since
https://reviews.llvm.org/D71894, so this patch fixes the issue for
Apple platforms to unblock our CI.
This fixes using non-default locales, which currently can crash when
e.g. formatting numbers.
Within the localeconv_l function, the per-thread locale is temporarily
changed with __libcpp_locale_guard, then localeconv() is called,
returning an lconv * struct pointer.
When localeconv_l returns, the __libcpp_locale_guard dtor restores
the per-thread locale back to the original. This invalidates the
contents of the earlier returned lconv struct, and all C strings
that are pointed to within it are also invalidated.
Thus, to have an actually working localeconv_l function, the
function needs to allocate some sort of storage for the returned
contents, that stays valid for as long as the caller needs to use
the returned struct.
Extend the libcxx/win32 specific locale_t class with storage for
a deep copy of a lconv struct, and change localeconv_l to take
a reference to the locale_t, to allow it to store the returned
lconv struct there.
This works fine for libcxx itself, but wouldn't necessarily be right
for a caller that uses libcxx's localeconv_l function.
This fixes around 11 of libcxx's currently failing tests on windows.
Differential Revision: https://reviews.llvm.org/D69505
libc++ on Android needs to be linked against libandroid_support on API
levels less than 21 to provide needed functions that aren't in the libc
on those platforms (e.g. posix_memalign for libcxxabi). libc++ from the
NDK is a linker script that pulls in libandroid_support, but for
building libc++ itself, we need to explicitly add libandroid_support as
a dependency. Moreover, libc++ headers reference the functions provided
by libandroid_support, so it needs to be added as a public dependency.
Differential Revision: https://reviews.llvm.org/D73516
Summary:
The libcxx test suite auto-detects spaceship operator, but __config does not. This means that the libcxx test suite has been broken for over a month when using top-of-tree clang. This also really ought to be fixed before 10.0.
See: bc633a42dd
Reviewers: chandlerc, mclow.lists, EricWF, ldionne, CaseyCarter
Reviewed By: EricWF
Subscribers: broadwaylamb, hans, dexonsmith, tstellar, llvm-commits, libcxx-commits
Tags: #libc, #llvm
Differential Revision: https://reviews.llvm.org/D72980
Summary:
The compiler already treats them as scalar types, so the library should
too. Furthermore, this allows blocks to be used in more places, for
example in std::optional, which requires an object type.
rdar://problem/57892832
Reviewers: dexonsmith, EricWF, mclow.lists
Differential Revision: https://reviews.llvm.org/D72708
This reverts commit a8a9c8e0a1.
There are multiple reported failures caused by this change.
Each failure is really weird, but it makes sense to revert
while investigating.
builds.
Fix a libc++abi test that was incorrectly checking for threading
primitives even when threading was disabled.
Additionally, temporarily XFAIL some module tests that fail because
the <atomic> header is unsupported but still built as a part of the
std module.
To properly address this libc++ would either need to produce a different
module.modulemap for single-threaded configurations, or it would need
to make the <atomic> header not hard-error and instead be empty
for single-threaded configurations
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
We switched to C11 thread API on Fuchsia in ab9aefe, but further
testing showed that Fuchsia's C11 mutex implementation needs a few
improvements for this to be usable, so we temporarily switch back
to the pthread implementation until those issues are addressed.
Differential Revision: https://reviews.llvm.org/D72862
The C11 API specifies that to initialize a recursive mutex,
mtx_plain | mtx_recursive should be used with mtx_init.
Differential Revision: https://reviews.llvm.org/D72809
The GCC build failures have been addressed, and the LLDB failures were
fixed by LLDB.
I have also verified that the apple-clang 9.0 segfault no longer
occurs.
Original Message:
The external instantiation of std::string is a problem for libc++.
Additions and removals of inline functions in string can cause ABI
breakages, including introducing new symbols.
This patch aims to:
(1) Make clear which functions are explicitly instatiated.
(2) Prevent new functions from being accidentally instantiated.
(3) Allow a migration path for adding or removing functions from the
explicit instantiation over time.
Although this new formulation is uglier, it is preferable from a
maintainability and readability standpoint because it explicitly
enumerates the functions we've chosen to expose in our ABI. Changing
this list is non-trivial and requires thought and planning.
(3) is achieved by making it possible to control the extern template declaration
separately from it's definition. Meaning we could add a new definition to
the dylib, wait for it to roll out, then add the extern template
declaration to the header. Similarly, we could remove existing extern
template declarations while still keeping the definition to prevent ABI
breakages.
This patch is needed in order to work around a GCC bug that fails to
explicitly instantiate a non-template function of a class template when
there is another overload that's a function template.
(See https://godbolt.org/z/4bUQ_b)
This patch SFINAE's away the function templates when the argument is
a basic_string.
On Fuchsia, pthread API is emulated on top of C11 thread API. Using C11
thread API directly is more efficient.
While this implementation is only used by Fuchsia at the moment, it's
not Fuchsia specific, and could be used by other platforms that use C11
threads rather than pthreads in the future.
Differential Revision: https://reviews.llvm.org/D64378
This also makes this function consistent with the rest of the
libc++ provided fallbacks.
The locale support in msvcrt.dll is very limited anyway; it can
only be configured processwide, not per thread, and it only seems
to support the locales "C" and "" (the user set locale), so it's
hard to make any meaningful automatic test for it. But manually tested,
this change does make time formatting locale code in libc++ output
times in the user requested format, when using locale "".
Differential Revision: https://reviews.llvm.org/D69554
Summary:
The `LIBCXX_CXX_ABI_LIBRARY_PATH` CMake variable is cached once in
libcxx/cmake/Modules/HandleLibCXXABI.cmake in the `setup_abi_lib` macro,
and then cached again in libcxx/test/CMakeLists.txt. There, if it is
not set to a value, it is by default set to `LIBCXX_LIBRARY_DIR`.
However, this new value is not actually cached, because the old (empty)
value has been already cached. Use the `FORCE` CMake flag so that it
is saved to the cache.
This should not break anything, because the code changed here previously
had no effect, when it should have.
Reviewers: jroelofs, bcraig, ldionne, EricWF, mclow.lists, vvereschaka, eastig
Reviewed By: vvereschaka
Subscribers: mgorny, christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D69169
The external instantiation of std::string is a problem for libc++.
Additions and removals of inline functions in string can cause ABI
breakages, including introducing new symbols.
This patch aims to:
(1) Make clear which functions are explicitly instatiated.
(2) Prevent new functions from being accidentally instantiated.
(3) Allow a migration path for adding or removing functions from the
explicit instantiation over time.
Although this new formulation is uglier, it is preferable from a
maintainability and readability standpoint because it explicitly
enumerates the functions we've chosen to expose in our ABI. Changing
this list is non-trivial and requires thought and planning.
(3) is achieved by making it possible to control the extern template declaration
separately from it's definition. Meaning we could add a new definition to
the dylib, wait for it to roll out, then add the extern template
declaration to the header. Similarly, we could remove existing extern
template declarations while still keeping the definition to prevent ABI
breakages.
span.cons/container.pass.cpp
N4842 22.7.3.2 [span.cons]/13 constrains span's range constructor
for ranges::contiguous_range (among other criteria).
24.4.5 [range.refinements]/2 says that contiguous_range requires data(),
and (via contiguous_range, random_access_range, bidirectional_range,
forward_range, input_range, range) it also requires begin() and end()
(see 24.4.2 [range.range]/1).
Therefore, IsAContainer needs to provide begin() and end().
(Detected by MSVC's concept-constrained implementation.)
span.cons/stdarray.pass.cpp
This test uses std::array, so it must include <array>.
<span> isn't guaranteed to drag in <array>.
(Detected by MSVC's implementation which uses a forward declaration to
avoid dragging in <array>, for increased compiler throughput.)
span.objectrep/as_bytes.pass.cpp
span.objectrep/as_writable_bytes.pass.cpp
Testing `sp.extent == std::dynamic_extent` triggers MSVC warning
C4127 "conditional expression is constant". Using `if constexpr` is a
simple way to avoid this without disrupting anyone else (as span
requires C++20 mode).
span.tuple/get.pass.cpp
22.7.3.2 [span.cons]/4.3: "Preconditions: If extent is not equal to
dynamic_extent, then count is equal to extent."
These lines were triggering undefined behavior (detected by assertions
in MSVC's implementation).
I changed the count arguments in the first two chunks, followed by
changing the span extents, in order to preserve the test's coverage
and follow the existing pattern.
span.cons/span.pass.cpp
22.7.3.2 [span.cons]/18.1 constrains span's converting constructor with
"Extent == dynamic_extent || Extent == OtherExtent is true".
This means that converting from dynamic extent to static extent is
not allowed. (Other constructors tested elsewhere, like
span(It first, size_type count), can be used to write such code.)
As this is the test for the converting constructor, I have:
* Removed the "dynamic -> static" case from checkCV(), which is
comprehensive.
* Changed the initialization of std::span<T, 0> s1{}; in
testConstexprSpan() and testRuntimeSpan(), because s1 is used below.
* Removed ASSERT_NOEXCEPT(std::span<T, 0>{s0}); from those functions,
as they are otherwise comprehensive.
* Deleted testConversionSpan() entirely. Note that this could never
compile (it had a bool return type, but forgot to say `return`). And it
couldn't have provided useful coverage, as the /18.2 constraint
"OtherElementType(*)[] is convertible to ElementType(*)[]"
permits only cv-qualifications, which are already tested by checkCV().
Summary:
`__has_attribute(fallthough)` -> `__has_attribute(fallthrough)`
This is a follow-up of https://reviews.llvm.org/D72287
Reviewers: EricWF, mclow.lists, Jim
Reviewed By: Jim
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D72314
This change adds the following benchmarks:
- StringAssignStr
Assign a const basic::string& value
- StringAssignAsciiz
Assign a const char* asciiz value
StringAssignAsciizMix
Assign mixed long/short const char* asciiz values
- StringResizeDefaultInit
Resize default init benchmark
Patch by Martijn Vels (mvels@google.com)
Reviewed as D72343
Add NetBSD to the same feature list as Fuchsia since it matches
in available features, effectively enabling aligned_alloc(),
timespec_get() and C11 features. Remove now-duplicate declaration
of quick_exit() support.
Differential Revision: https://reviews.llvm.org/D71511
Summary:
When testing an installed (out-of-tree) version of libc++, the
"libcxx/fuzzing/partial_sort.pass.cpp" test fails because of missing
include files "../fuzzing/fuzzing.{h,cpp}". This happens because in
the source tree "../fuzzing" can be accessed as
"libcxx/include/../fuzzing", but with the installed library this does
not work.
This patch fixes the issue by changing the path to be relative from
the `libcxx/test/fuzzing" directory.
Reviewers: mclow.lists, EricWF, christof, michaelplatings
Reviewed By: michaelplatings
Subscribers: merge_guards_bot, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71459
This patch de-duplicates most compressed pair constructors
to use the same code in C++11 and C++03.
Part of doing that is deleting the "__second_tag()" and replacing
it with a "__value_init_tag()" which has the same effect, but
allows for the removal of the special "one-arg" first element
constructor.
This patch is intended to have no semantic change.
This change introduces the __default_init_tag to memory, and a corresponding
element constructor to allow for default initialization of either of the pair
values. This is useful for classes such as std::string where most (all)
constructors explicitly initialize the values in the constructor.
Patch by Martijn Vels (mvels@google.com)
Reviewed as https://reviews.llvm.org/D70617
libcxx/test/std/containers/sequences/array/at.pass.cpp
Need to include <stdexcept> for std::out_of_range.
libcxx/test/std/localization/locale.categories/category.time/*
Need to include <ios> for std::ios.
[libcxx] [test] Calling min and max on an empty valarray is UB.
libcxx/test/std/numerics/numarray/template.valarray/valarray.members/min.pass.cpp
libcxx/test/std/numerics/numarray/template.valarray/valarray.members/max.pass.cpp
The calls `v1.min();` and `v1.max();` were emitting nodiscard warnings
with MSVC's STL. Upon closer inspection, these calls were triggering
undefined behavior. N4842 [valarray.members] says:
"T min() const;
8 Preconditions: size() > 0 is true.
T max() const;
10 Preconditions: size() > 0 is true."
As these tests already provide coverage for non-empty valarrays
(immediately above), I've simply deleted the code for empty valarrays.
[libcxx] [test] Add macros to msvc_stdlib_force_include.h (NFC).
libcxx/test/support/msvc_stdlib_force_include.h
These macros are being used by:
libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/result_of11.pass.cpp
Defining them to nothing allows that test to pass.
[libcxx] [test] Silence MSVC warning C5063 for is_constant_evaluated (NFC).
libcxx/test/std/utilities/meta/meta.const.eval/is_constant_evaluated.pass.cpp
This test is intentionally writing code that MSVC intentionally warns
about, so the warning should be silenced.
Additionally, comment an endif for clarity.
[libcxx] [test] Silence MSVC warning C4127 (NFC).
libcxx/test/support/charconv_test_helpers.h
MSVC avoids emitting this warning when it sees a single constexpr value
being tested, but this condition is a mix of compile-time and run-time.
Using push-disable-pop is the least intrusive way to silence this.
[libcxx] [test] Silence MSVC truncation warning (NFC).
libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp
This test is intentionally truncating float to int, which MSVC
intentionally warns about, so push-disable-pop is necessary.
[libcxx] [test] Avoid truncation warnings in erase_if tests (NFC).
libcxx/test/std/containers/associative/map/map.erasure/erase_if.pass.cpp
libcxx/test/std/containers/associative/multimap/multimap.erasure/erase_if.pass.cpp
libcxx/test/std/containers/unord/unord.map/erase_if.pass.cpp
libcxx/test/std/containers/unord/unord.multimap/erase_if.pass.cpp
These tests use maps with `short` keys and values, emitting MSVC
truncation warnings from `int`. Adding `static_cast` to `key_type`
and `mapped_type` avoids these warnings.
As these tests require C++20 mode (or newer), for brevity I've changed
the multimap tests to use emplace to initialize the test data.
This has no effect on the erase_if testing.
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.
Since C++11, [depr.impldec]:
The implicit definition of a copy constructor as defaulted is deprecated
if the class has a user-declared copy assignment operator or a
user-declared destructor.
At clang HEAD, -Wdeprecated-copy (included by -Wextra) will warn on such instances.
Reviewed By: EricWF
Differential Revision: https://reviews.llvm.org/D71096
LLVM has moved to C++14, and the libc++ build should too.
C++14 is needed to provide constant initialization for certain global
objects.
I suspect this change may break some older GCC buildbots, and I'll clean
those up as they fall.
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
Louis Dionne