As PR56606 stated, the current implementation of CityHash in libc++
would drop some bits unintentionally. Cast the 32bit int to the 64bit
int to avoid this happened.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D134124
This concept is introduced in P2286, but was implemented in libc++
before. This implementation was used in the library internally. This
implementation lacked the resolution of LWG3636. The original formatter
had a non-const member function that wasn't trivial to make a const
member. The recent parser improvements made this member a const member
in preparation of LWG3636.
Note LWG3636 isn't voted in. Its status is Ready. P2286's concept has
been written as-if LWG3636 is accepted and refers to that LWG issue.
Updates some tests make format a const member function and removes a
tests that's mainly a duplicate of the formattable concept test.
Implements
- LWG3636 formatter<T>::format should be const-qualified
Implements parts of
- P2286R8 Formatting Ranges
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D134110
This adds support for the new code points in the Extended Grapheme
Cluster algorithm. The algorithm itself has remained unchanged.
The width estimation still follows the rules of the Standard.
@cor3ntin filed
LWG3780 format's width estimation is too approximate and not forward compatible
to improve the estimate.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D134106
This is a breaking change. If you were passing one of those three runtimes
in LLVM_ENABLE_PROJECTS, you need to start passing them in LLVM_ENABLE_RUNTIMES
instead. The runtimes in LLVM_ENABLE_RUNTIMES will start being built using
the "bootstrapping build" instead, which means that they will be built
using the just-built Clang. This is usually what you wanted anyway.
If you were using LLVM_ENABLE_PROJECTS=all with the explicit goal of
building these three runtimes, you can now use LLVM_ENABLE_RUNTIMES=all
and these runtimes will be built using the bootstrapping build.
NOTE: This is a re-application of 887b8bd733 which had been reverted
in 6b03a4fea0 because it broke the Sphinx documentation publishers.
The Sphinx documentation publishers have now been moved to using
the runtimes build, so this should not be an issue anymore.
Differential Revision: https://reviews.llvm.org/D132480
This patch enables libc++ build as shared library in all combinations of ASCII/EBCDIC and 32-bit/64-bit variants. In particular it introduces:
# ASCII version of libc++ named as libc++_a.so
# Script to rename DLL name inside the generated side deck
# Various names for dataset members where DLL libraries and their side decks will reside
# Add the following options:
- LIBCXX_SHARED_OUTPUT_NAME
- LIBCXX_ADDITIONAL_COMPILE_FLAGS
- LIBCXX_ADDITIONAL_LIBRARIES
- LIBCXXABI_ADDITIONAL_COMPILE_FLAGS
- LIBCXXABI_ADDITIONAL_LIBRARIES
**Background and rational of this patch**
The linker on z/OS creates a list of exported symbols in a file called side deck. The list contains the symbol name as well as the name of the DLL which implements the symbol. The name of the DLL depends on what is specified in the -o command line option. If it points to a USS file, than the DLL name in the side deck will be the USS file name. If it points to a member of a dataset then the DLL name in the side deck is the member name.
If CMake could deal with z/OS datasets we could use -o that points to a dataset member name, but this does not seem to work so we have to produce a USS file as the DLL and then copy the content of the produced side deck to a dataset as well as rename the USS file name in the side deck to a dataset member name that corresponds to that DLL.
Reviewed By: muiez, SeanP, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D118503
This patch incorporates the "sanitize" step of the transitive includes
test into the CSV generator itself. In doing so, it removes complexity
in the test but also fixes a bug where we would filter out <__mutex>
from the output, leading to an incorrect list of includes for the
<shared_mutex> header.
Differential Revision: https://reviews.llvm.org/D134830
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
This is a re-application of the original patch by Eric Fiselier in
fcd549a7d8 which had been reverted due to reasons lost at this point.
I also added the macro to a few more types. Reviving this patch was
prompted by the discussion on https://llvm.org/D133425.
Differential Revision: https://reviews.llvm.org/D133535
Round-tripping pointers via size_t is not portable, the C/C++ standards
only require this to be valid when using (u)intptr_t.
Originally committed to the CHERI fork of LLVM as
dd01245185,
but I forgot to upstream the change. I rediscovered this issue due to a
compiler warning when building libc++ on a Arm Morello system.
Reviewed By: #libc, ldionne, philnik
Differential Revision: https://reviews.llvm.org/D134363
Instead of using `reverse_iterator`, share the optimization between the 4 algorithms. The key observation here that `memmove` applies to both `copy` and `move` identically, and to their `_backward` versions very similarly. All algorithms now follow the same pattern along the lines of:
```
if constexpr (can_memmove<InIter, OutIter>) {
memmove(first, last, out);
} else {
naive_implementation(first, last, out);
}
```
A follow-up will delete `unconstrained_reverse_iterator`.
This patch removes duplication and divergence between `std::copy`, `std::move` and `std::move_backward`. It also improves testing:
- the test for whether the optimization is used only applied to `std::copy` and, more importantly, was essentially a no-op because it would still pass if the optimization was not used;
- there were no tests to make sure the optimization is not used when the effect would be visible.
Differential Revision: https://reviews.llvm.org/D130695
Implement LWG 3629, by making lookup for make_error_code and
make_error_condition only consider names found by ADL. This is achieved
by adding a block scope using-declaration for a function that will be
found by unqualified lookup, preventing unqualified lookup from
continuing to enclosing scopes (the class scope, then enclosing
namespaces). The function named by the using declaration is not
viable, so overload resolution must select a candidate found by ADL.
This fixes https://github.com/llvm/llvm-project/issues/57614
Differential Revision: https://reviews.llvm.org/D134943
Now that all jobs have moved over to the new style of Lit configuration,
we can remove all traces of the legacy testing configuration system.
This includes:
- Cache settings that are not honored or useful anymore
- Several CMake options that were only useful in the context of the
legacy Lit configuration system
- A bunch of Python support code that is not used anymore
- The legacy lit.cfg.in files themselves
Differential Revision: https://reviews.llvm.org/D134650
By default, Clang does not include headers that are skipped due to
the include guard optimization in the --trace-includes output, which
breaks the use case that we were trying to use it for.
However, Clang does support the -fshow-skipped-includes flag, which
does exactly what we need and will result in an accurate include
graph.
As a fly-by fix, make sure that our includes don't differ between
-fexceptions and -fno-exceptions.
Differential Revision: https://reviews.llvm.org/D134829
Noticed this while working on D133326. Let's see whehter all compilers
now support this feature.
Reviewed By: #libc, philnik, ldionne
Differential Revision: https://reviews.llvm.org/D134818
We should strive to have our own tests, except when there is overwhelming
value in using another standard library's existing tests. The reason is
that it ensures that implementations don't all start relying on the same
interpretation of the Standard.
The unique_ptr tests did not add any test coverage AFAICT, and the
forward_like tests were moved to the style used everywhere in the
libc++ test suite.
Note that I got to this because this actually broke a downstream
configuration where we use -ffreestanding. The signature of main()
was not consistent with the signature we (need to) use everywhere
in the test suite.
Differential Revision: https://reviews.llvm.org/D134767
If a C source file includes the libc++ stdatomic.h, compilation will
break because (a) the C++ standard check will fail (which is expected),
and (b) `_LIBCPP_COMPILER_CLANG_BASED` won't be defined because the
logic defining it in `__config` is guarded by a `__cplusplus` check, so
we'll end up with a blank header. Move the detection logic outside of
the `__cplusplus` check to make the second check pass even in a C context
when you're using Clang. Note that `_LIBCPP_STD_VER` is not defined when
in C mode, hence stdatomic.h needs to check if in C++ mode before using
that macro to avoid a warning.
In an ideal world, a C source file wouldn't be including the libc++
header directory in its search path, so we'd never have this issue.
Unfortunately, certain build environments make this hard to guarantee,
and in this case it's easy to tweak this header to make it work in a C
context, so I'm hoping this is acceptable.
Fixes https://github.com/llvm/llvm-project/issues/57710.
Differential Revision: https://reviews.llvm.org/D134591
Currently if both LIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY (only
applies to static library) and LIBCXX_ENABLE_ABI_LINKER_SCRIPT (only
applies to shared library) are enabled, the former will be silently
ignored. The shared library will use a linker script, while the
static library fails to link libc++abi.a entirely.
This is caused by what appears to be an implementation bug: The
LIBCXX_STATICALLY_LINK_ABI_IN_*_LIBRARY options are declared as
dependent options of LIBCXX_ENABLE_STATIC_ABI_LIBRARY, rather than
simply using it as the default value.
Of course, the combination of
LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY and
LIBCXX_ENABLE_ABI_LINKER_SCRIPT still results in a cmake error,
because these would be conflicting requests for the shared library.
Differential Revision: https://reviews.llvm.org/D134644
In the implementation of `std::views::take`, it uses `subrange<Iter>` as part of the return type. But in case of input iterator, `subrange<Iter>` can be ill-formed
Differential Revision: https://reviews.llvm.org/D133220
The new version is a lot simpler and has less option which were not
used. This uses the CSV files as generated by D133127 as input data.
The current Python script has more features but uses a simple "grep"
making the output less accurate:
- Conditionally included header are always included. This is an issue
since part of our includes are unneeded transitive includes. Based on
the language version they may be omitted. The script however always
includes them.
- Includes in comments are processed as-if they are includes. This is an
issue when comments explain how certain data is generated; of course
there are digraphs which the script omits.
This implementation uses Clang's --trace-includes to generate the includes
per header. This means the input of the generation script always has the
real list of includes.
Libc++ is moving from large monolithic Standard headers to more fine
grained headers. For example, algorithm includes every header in
`__algorithm`. Adding all these detail headers in the graph makes the
output unusable. Instead it only shows the Standard headers. The
transitive includes of the detail headers are parsed and "attributed" to
the Standard header including them. This gives an accurate include graph
without the unneeded clutter. Note that this graph is still big.
This changes fixes the cyclic dependency issue with the previous version
of the tool so the markers and its documentation is removed.
Since the input has no cycles the CI test is removed.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D134188
This test generates the include graph of the Standard headers of libc++ in
a CSV file. This was originally used to generate graphviz dot files. During
review it was noticed these files have all information needed to replace
the current transitive includes. Therefore the output, with the same information as the .dot file is stored in a .csv file. This removes
all the existing transitive include files.
The .cvs can be converted by a .dot file by the script in D134188.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D133127
While testing a test failure of C++17 with Clang ToT it was noticed the
paper
P0602R4 variant and optional should propagate copy/move triviality
was not applied as a DR in libc++.
This was discovered while investigating the issue "caused by" D131479.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D133326
Update the formatter day tests to the new style.
Other test will be done separately.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D134031
Switch to the new granular format_functions header. Since the chrono's
format dependency in C++20 hasn't been in a release it's save to remove
it.
Depends on D133665
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D133796
This is a breaking change. If you were passing one of those three runtimes
in LLVM_ENABLE_PROJECTS, you need to start passing them in LLVM_ENABLE_RUNTIMES
instead. The runtimes in LLVM_ENABLE_RUNTIMES will start being built using
the "bootstrapping build" instead, which means that they will be built
using the just-built Clang. This is usually what you wanted anyway.
If you were using LLVM_ENABLE_PROJECTS=all with the explicit goal of
building these three runtimes, you can now use LLVM_ENABLE_RUNTIMES=all
and these runtimes will be built using the bootstrapping build.
Differential Revision: https://reviews.llvm.org/D132480
It's been one and a half months now and nobody said anything, so I guess this code can be removed.
Reviewed By: ldionne, #libc
Spies: Mordante, libcxx-commits, mgorny, mstorsjo
Differential Revision: https://reviews.llvm.org/D132943
Using the `enable_if_t<..., int> = 0` style has the benefit that it works in all cases and makes function declarations easier to read because the function arguments and return type and SFINAE are separated. Unifying the style also makes it easier for people not super familiar with SFINAE to make sense of the code.
Reviewed By: Mordante, var-const, #libc, huixie90
Spies: huixie90, libcxx-commits
Differential Revision: https://reviews.llvm.org/D131868
In https://llvm.org/D56913, we added an emulation for the __atomic_always_lock_free
compiler builtin when compiling in Freestanding mode. However, the emulation
did (and could not) give exactly the same answer as the compiler builtin,
which led to a potential ABI break for e.g. enum classes.
After speaking to the original author of D56913, we agree that the correct
behavior is to instead always use the compiler builtin, since that provides
a more accurate answer, and __atomic_always_lock_free is a purely front-end
builtin which doesn't require any runtime support. Furthermore, it is
available regardless of the Standard mode (see https://godbolt.org/z/cazf3ssYY).
However, this patch does constitute an ABI break. As shown by https://godbolt.org/z/1eoex6zdK:
- In LLVM <= 11.0.1, an atomic<enum class with 1 byte> would not contain a lock byte.
- In LLVM >= 12.0.0, an atomic<enum class with 1 byte> would contain a lock byte.
This patch breaks the ABI again to bring it back to 1 byte, which seems
like the correct thing to do.
Fixes#57440
Differential Revision: https://reviews.llvm.org/D133377
compressed_pair is widely used in the library, but most of the uses don't use the tuple parts. To avoid including <tuple> everywhere, use the forward declaration instead in compressed_pair.h
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D133331
Nikolas Klauser