Summary: The default constructor for shared_ptr and shared_ptr::__enable_weak_this are both noexcept so, shared_ptr::__create_with_control_block can also be marked noexcept.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80070
Summary: In std::functional moves the reference out of the `__callable` implementation and replaces `_EnableIfCallable` with `_EnableIfLValueCallable` (`_EnableIfLValueCallable` passes `__callable` an lvalue reference type).
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80071
These two tests were clumsily using time measurements to determine
whether std::lock_guard was working correctly. In practice, this
approach merely verified that the underlying lock properly waits.
Now these two tests verify that lock is acquired, not dropped
prematurely, and finally, actually dropped at the end of the scope.
Like other uses of ALLOW_RETRIES, this test tried to verify that an API
returned "quickly" but quick is not safe to define given slow and/or
busy machines.
Instead, we now verify that these "wait" APIs actually wait, which the
old test did not.
* improve coverage in `span`'s "conversion from `std::array`" test, while eliminating MSVC diagnostics about `testConstructorArray<T>() && testConstructorArray<const T, T>()` being redundant when `T` is already `const`.
* Remove use of `is_assignable` that triggers UB due to an insufficiently-complete type argument in `std::function`'s assignment operator test.
* Don't test that `shared_ptr` initialization from an rvalue triggers the lvalue aliasing constructor on non-libc++; this is not the case for Standard Libraries that implement LWG-2996. (Ditto, I'd simply remove this but it's your library ;).)
Differential Revision: https://reviews.llvm.org/D80030
We already set it using -rpath when linking test executables, and using
DYLD_LIBRARY_PATH causes problems when running other commands that
shouldn't run against the just-built libc++ (e.g. `ls` in a ShTest).
rdar://63241847
Since we're using the new testing format, DYLD_LIBRARY_PATH is not passed
to the compiler -- it's only passed to the programs we run as an argument
to the %{exec} substitution.
This is already handled by setting cxx_runtime_root instead -- I don't
see a reason to have two ways of setting the runtime path of the library
we're running against.
Because of Python's funny scoping rules with lambdas, we were always
using the value of `macro` as set in the last iteration of the loop.
This problem was introduced by e7bdfba4f0.
Otherwise, specifying (for example) the libc++.dylib from macos10.13
but the libc++abi.dylib from macos10.12 would end up adding library
paths for both the 10.12 and 10.13 dylibs, which would each contain
a copy of both libc++abi.dylib and libc++.dylib. By using a separate
directory for libc++.dylib and libc++abi.dylib, those do not conflict
anymore.
The back-deployment roots were updated to match this change.
This implements the relaxed requirements on the std::array constructors of span,
where the type only needs to be convertible to the element type of the span.
Note that the previous tests were not sufficient, as the const array<T, n> constructor
was only tested for compile time and the array<T, N> only during runtime.
Restructure the tests so that we can test conversions as well as both constructors.
Differential Revision: https://reviews.llvm.org/D75706
The default constructor of a static span requires _Extent == 0 so
SFINAE it out rather than using a static_assert
Differential Revision: https://reviews.llvm.org/D71994
unistd.h isn't guaranteed to exist when the target isn't Windows, in
particular if the target is bare-metal (i.e. no operating system).
Handle this by using __has_include instead, though in
filesystem/operations.cpp we already unconditionally include it so
just remove the extra include.
Differential Revision: https://reviews.llvm.org/D79784
These two tests do not use the "thread sleeps X milliseconds" pattern
that other libcxx tests use, so all we can do in order to remove
ALLOW_RETRIES workaround is remove the assumption that measuring the
"quick" return of `wait()` is possible (it is not). Let the test harness
verify overall that `wait()` does not hang.
As a bonus, have the spin-waiting threads `yield()`, which is what well
behaved code should do.
When grepping for unused features in the test suite, we will now find
those features and where they are defined, as opposed to thinking they
are dead features.
This test tried to verify that "wait()" returned quickly but "quick" is
impossible to define given a busy and/or slow system.
Instead, I've refactored the test to verify that `wait()` actually
waits which the old test did not verify.
Summary:
This LWG issue states that the result of `year_month_day_last::day()` is implementation defined if `ok()` is `false`.
However, from user perspective, calling `day()` in this situation will lead to a (possibly difficult to find) crash.
Hence, I have added an assertion to warn user at least when assertions are enabled.
I am however not aware of the libc++ stand on the desired behaviour.
Reviewers: ldionne, mclow.lists, EricWF, #libc
Reviewed By: ldionne, #libc
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D70346
Implements P0414R2:
* Adds support for array types in std::shared_ptr.
* Adds reinterpret_pointer_cast for shared_ptr.
Re-committing now that the leaking tests are fixed.
Differential Revision: https://reviews.llvm.org/D62259
Operating systems are best effort by default, so we cannot assume that
sleep-like APIs return as soon as we'd like.
Even if a sleep-like API returns when we want it to, the potential for
preemption means that attempts to measure time are subject to delays.
Implements P0414R2:
* Adds support for array types in std::shared_ptr.
* Adds reinterpret_pointer_cast for shared_ptr.
Differential Revision: https://reviews.llvm.org/D62259
Operating systems are best effort by default, so we cannot assume that
sleep-like APIs return as soon as we'd like.
Even if a sleep-like API returns when we want it to, the potential for
preemption means that attempts to measure time are subject to delays.
The challenge with measuring time in tests is that slow and/or busy
machines can cause tests to fail in unexpected ways. After this change,
three tests should be much more robust. The only remaining and tiny race
that I can think of is preemption after `--countDown`. That being said,
the race isn't fixable because the standard library doesn't provide a
way to count threads that are waiting to acquire a lock.
Reviewers: ldionne, EricWF, howard.hinnant, mclow.lists, #libc
Reviewed By: ldionne, #libc
Subscribers: dexonsmith, jfb, broadwaylamb, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D79406
This commit should will break libc++ without local submodule visibility, but
the LLVM+modules bots are now all using this mode. Before the Green Dragon
LLDB bot was failing to compile with a libc++ built with this commit as LSV
was disabled on macOS.
Original summary:
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.
This change adds test coverage for the `codecvt<char16_t, char8_t, mbstate_t>` and `codecvt<char32_t, char8_t, mbstate_t>` ctype facets added to the C++20 WD by [P0482R6](https://wg21.link/P0428R6). Note that libc++ does not implement these facets despite implementing the remainder of P0482, presumably for ABI reasons, so these tests are marked `UNSUPPORTED: libc++`.
The ostream operator<< is currently broken for std::complex with
specified field widths.
This patch a partial revert of c3478eff7a (reviewed as D71214),
restoring the correct behavior.
Differential Revision: https://reviews.llvm.org/D78816
clock_gettime is documented to be available when _POSIX_TIMERS is
defined. Add a check for this.
Differential Revision: https://reviews.llvm.org/D79305
These tests fail due to a couple of changes to `move_iterator` for C++20:
* `move_iterator<I>::operator++(int)` returns `void` in C++20 if `I` doesn't model `forward_iterator`.
* `move_iterator<I>::reference` is calculated in C++20, so `I` must actually have an `operator*() const`.
Differential Revision: https://reviews.llvm.org/D79343
This patch adds deduction guides to <memory> to allow deducing
construction of shared_ptrs from unique_ptrs, and from weak_ptrs
and vice versa, as specified by C++17.
Differential Revision: https://reviews.llvm.org/D69603
This patch adds `_VSTD::` to some calls to `make_pair` inside the
implementations of searchers, to prevent things exploding if there is
a make_pair in an associated namespace of a user-defined type.
https://godbolt.org/z/xAFG98
Differential Revision: https://reviews.llvm.org/D72640
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.
zoecarver