When run in a git bash terminal, sys.stderr isn't flushed implicitly
after printing each line. Manually flush it after each printout,
to avoid getting broken/misordered output.
A similar fix had been done in the old libcxx test config, committed
as part of 7e3ee09ad2 / D28725; this
generalizes the fix, making it available in the new libcxx test
configs too, and for any other test that uses lit_config.note().
Differential Revision: https://reviews.llvm.org/D115761
A few tests in the test suite require support for Bash. For example,
tests that run a program and send data through stdin to it require some
way of piping the data in, and we use a Bash script for that.
However, some executors (e.g. an embedded systems simulator) do not
support Bash, so these tests will fail. This commit adds a Lit feature
that tries to detect whether Bash is available through conventional
means, and disables the tests that require it otherwise.
Differential Revision: https://reviews.llvm.org/D114612
There's a lot of history behind this, so here's a summary:
1. I stopped forcing -fPIC when building the runtimes in 30f305efe2,
before the LLVM 9 release back in 2019.
2. Someone complained that libc++.a couldn't be used in shared libraries
built without -fPIC (http://llvm.org/PR43604) since the LLVM 9 release.
This had been caused by my removal of -fPIC when building libc++.a in (1).
3. I suggested two ways of fixing the issue, the first being to force
-fPIC back unconditionally (http://llvm.org/D104328), and the second
being to specify that option explicitly when building the LLVM release
(http://llvm.org/D104327). We converged on the first solution.
4. I landed D104328, which forced building the runtimes with -fPIC.
This was included in the LLVM 13.0 release.
5. People complained about that and requested that we be able to
customize this setting (basically we should have done the second
solution).
This patch makes it such that the LLVM release script will specifically
ask for building with -fPIC using CMAKE_POSITION_INDEPENDENT_CODE,
however by default the runtimes will not force that option onto users.
This patch has the unintended effect that Clang and the LLVM libraries
(not only the runtime ones like libc++) will also be built with -fPIC
in the release. It would be better if we could specify that -fPIC is to
be used only when building the runtimes, however this is left as a
future improvement. The release should probably be using a bootstrapping
build and passing those options to the stage that builds the runtimes
only, see https://reviews.llvm.org/D112748 for that change.
Differential Revision: https://reviews.llvm.org/D110261
This has been supported on gdb for something like ~10 years, so doesn't
seem necessary to carry a fallback.
Differential Revision: https://reviews.llvm.org/D114986
Seems better to rely on the existing formatting, makes the output
smaller/simpler - this is consistent with libstdc++'s std::string_view
pretty printing too.
Differential Revision: https://reviews.llvm.org/D113244
This patch removes the ability to build the runtimes in the 32 bit
multilib configuration, i.e. using -m32. Instead of doing this, one
should cross-compile the runtimes for the appropriate target triple,
like we do for all other triples.
As it stands, -m32 has several issues, which all seem to be related to
the fact that it's not well supported by the operating systems that
libc++ support. The simplest path towards fixing this is to remove
support for the configuration, which is also the best course of action
if there is little interest for keeping that configuration. If there
is a desire to keep this configuration around, we'll need to do some
work to figure out the underlying issues and fix them.
Differential Revision: https://reviews.llvm.org/D114473
This removes the `format_args_t` from `<format>` and adjusts the type of
the `format_args` for the `vformat_to` overloads.
The `format_context` uses a `back_insert_iterator<string>` therefore the
new `output_iterator` function uses a `string` as its temporary storage
buffer. This isn't ideal. The next patches in this series will improve
this. These improvements make it easy to also improve `format_to_n` and
`formatted_size`.
This addresses P2216 `6. Binary size`.
P2216 `5. Compile-time checks` are not part of this change.
Implements parts of:
- P2216 std::format improvements
Depends on D103670
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D110494
Instead of silently swallowing errors that happen during Lit configuration
(for example trying to obtain compiler macros but compiling fails), raise
an exception with some amount of helpful information.
This should avoid the possibility of silently configuring Lit in a bogus
way, and also provides more helpful information when things fail.
Note that this requires a bit more finesse around how we handle some
failing configuration checks that we would previously return None for.
Differential Revision: https://reviews.llvm.org/D114010
When testing with sanitizers enabled, we need to link against a plethora
of system libraries. Using `-nodefaultlibs` like we used to breaks this,
and we would have to add all these system libraries manually, which is
not portable and error prone. Instead, stop using `-nodefaultlibs` so
that we get the libraries added by default by the compiler.
The only caveat with this approach is that we are now relying on the
fact that `-L <path-to-local-libunwind>` will cause the just built
libunwind to be selected before the system implementation (either of
libunwind or libgcc_s.so), which is somewhat fragile.
This patch also turns the 32 bit multilib build into a soft failure
since we are in the process of removing it anyway, see D114473 for
details. This patch is incompatible with the 32 bit multilib build
because Ubuntu does not provide a proper libstdc++ for 32 bits, and
that is required when running with sanitizers enabled.
Differential Revision: https://reviews.llvm.org/D114385
Instead of having ad-hoc cleanup in various places, handle all creation
and removal of temporary files and directories inside _makeConfigTest.
As a fly-by, also remove testPrefix since we don't keep any source file
around anymore. Setting a prefix for the files is hence not useful anymore.
Differential Revision: https://reviews.llvm.org/D114390
At this point, every supported compiler that claims a -std=c++17 mode
should also support these features.
Differential Revision: https://reviews.llvm.org/D113436
We would have been defining it in <utility> instead of <charconv>. For
the time being, this doesn't change anything since we don't implement
the feature test macro anyways.
Also, as a fly-by, this removes obsolete feature test macro tests. There
was a brief time back in the days when we wrote feature test macro tests
manually. In particular, we had test files for __cpp_lib_to_chars and
__cpp_lib_memory_resource. Since we now have a principled way of generating
these tests with scripts, this commit removes the obsolete (and empty)
tests for these two feature test macros.
Differential Revision: https://reviews.llvm.org/D114243
We never noticed it because our CI doesn't actually build against a C
library that doesn't have threading functionality, however building
against a truly thread-free platform surfaces these issues.
Differential Revision: https://reviews.llvm.org/D114242
std::atomic is, for the most part, just a thin veneer on top of compiler
builtins. Hence, it should be available even when threads are not available
on the system, and in fact there has been requests for such support.
This patch:
- Moves __libcpp_thread_poll_with_backoff to its own header so it can
be used in <atomic> when threads are disabled.
- Adds a dummy backoff policy for atomic polling that doesn't know about
threads.
- Adjusts the <atomic> feature-test macros so they are provided even when
threads are disabled.
- Runs the <atomic> tests when threads are disabled.
rdar://77873569
Differential Revision: https://reviews.llvm.org/D114109
Mention support for MinGW in the docs. Rename the existing windows
CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much
"Windows", just different toolchain environments.
Add an XFAIL for a recently added test that fails in the MinGW DLL
configuration (with an explanation of what's causing the failure).
Differential Revision: https://reviews.llvm.org/D112215
This reverts commit e7568b68da and relands
c6f7b720ec.
The culprit was: missed that libc also had a dependency on one of the
copies of `google-benchmark`
Also opportunistically fixed indentation from prev. change.
Differential Revision: https://reviews.llvm.org/D112012
under third-party
This change:
- moves the libcxx copy of `google/benchmark` to
`third-party/benchmkark`
- points the 2 uses of the library (libcxx and llvm/utils) to this copy
We picked the licxx copy because it is the most up to date.
Differential Revision: https://reviews.llvm.org/D112012
Since coroutine is merged in C++ standard and the support for coroutine
seems relatively stable. It's the time to move the implementation of
coroutine out of the experimental directory and the std::experimental
namespace. This patch creates header <coroutine> with conformed
implementation with C++ standard. To avoid breaking user's code too
fast, the <experimental/coroutine> header is remained. Note that
<experimental/coroutine> is deprecated and it would be removed in
LLVM15.
Reviewed By: Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D109433
We don't use Python 2 anymore, so let us do the recommended fix instead
of using the workaround made for Python 2.
Differential Revision: https://reviews.llvm.org/D107715
We are trying to remove duplication of third-party code in
https://reviews.llvm.org/D112012, which will move the Google
Benchmark code outside of the `libcxx/` directory. That breaks
running the benchmarks in the Standalone build. Since we have
deprecated the Standalone build anyway, this patch just removes
support for the benchmark in Standalone mode until we remove that
mode entirely.
Differential Revision: https://reviews.llvm.org/D113503
Instead of hard-coding the target for our CI nodes, use the default
compiler triple. Also, allow building compiler-rt for the single
specified triple in case we're running on Darwin (otherwise, the
bootstrapping build complains).
Differential Revision: https://reviews.llvm.org/D113683
and to the new `runtimes` top level CMakeLists.txt since the old path is now deprecated. This requires a slight adjustment of the libcxxabi CMake, since there are required macro definitions we previously got via the `llvm/CMakeList.txt` path.
Reviewed By: ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D113403
At this point, every supported compiler that claims a -std=c++17 mode
should also support `if constexpr`. This was an issue for GCC 5
and GCC 6, but hasn't been an issue since GCC 7. (Our current
minimum supported GCC version, IIUC, is GCC 10 or 11.)
Differential Revision: https://reviews.llvm.org/D113348
This changes adds the pipeline config for both 32-bit and 64-bit AIX targets. As well, we add a lit feature `LIBCXX-AIX-FIXME` which is used to mark the failing tests which remain to be investigated on AIX, so that the CI produces a clean build.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D111359
[NFC] This patch fixes URLs containing "master". Old URLs were either broken or
redirecting to the new URL.
Reviewed By: #libc, ldionne, mehdi_amini
Differential Revision: https://reviews.llvm.org/D113186
Per our support plan we should now support Clang 12 and 13. Adjust the
documentation and the CI runners. The change indirectly moves the main
CI runners to use the Clang 14 nightly builds.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D112360
`utils/generate_feature_test_macro_components.py` uses the wrong
indentation. `:name: feature-status-table :widths: auto` is rendered as
text instead of being used by Sphinx to render the table properly.
This fixes the identation in the souce and updates the generated output.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D112251
This temporary FIXME really belongs to the testing config, not to the
specific CMake cache that enables that configuration.
Differential Revision: https://reviews.llvm.org/D112031
Running tests for libunwind is a lot simpler than running tests for
libc++, so a simple Lit config file is sufficient. The benefit is that
we disentangle the libunwind test configuration from the libc++ and
libc++abi test configuration. The setup was too complicated, which led
to some bugs (notably we were running against the system libunwind on
Apple platforms).
Differential Revision: https://reviews.llvm.org/D111664
This commit makes the new "runtimes" build (with <monorepo>/runtimes as
the root of the CMake invocation) the default way of building libc++.
The other supported way of building libc++ is the "bootstrapping" build,
where `<monorepo>/llvm` is used as the root of the CMake invocation.
All other ways of building libc++ are deprecated effective immediately.
There should be no use-case for building libc++ that isn't supported by
one of these two builds, and the two new builds work on all environments
and are lightweight. They will also make it possible to greatly simplify
the build infrastructure of the runtimes, which is currently way too
convoluted.
Differential Revision: https://reviews.llvm.org/D111356
That script is what we (need to) use to build libc++ for the system
configuration, so that's what we should test against. At some point
we may be able to fold all of that logic into the CMake build, and
when that happens the CI can go back to running CMake directly.
As a fly-by fix, stop mentioning x86_64 in the names of the Apple
jobs since they are not truly tied to any architecture.
Differential Revision: https://reviews.llvm.org/D111865
This initial change adds the AIX configuration to run-buildbot, an AIX
CMake cache file, and appropriate compiler and linker flags for testing
AIX to the lit "from scratch" configuration files. Either of the 32-bit or 64-bit configurations
can be built by setting `OBJECT_MODE` in the build environment (as is
typical for AIX).
Reviewed By: ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D111244
I came across an issue where since we build the library for Apple with
the install name directory being /usr/lib, which means that if we don't
run the tests with DYLD_LIBRARY_PATH, we'll end up loading the
system-provided libc++abi when running the tests. That wreaks havoc.
Instead of fixing it in the legacy config file, this commit introduces
an Apple libc++abi config file that does the right thing.
Differential Revision: https://reviews.llvm.org/D111279
Martin Storsjö