The OSS fuzz build has been broken for a while because of changes
to the cmake configuration. This patch fixes the issues by defaulting to
libunwind as the default runtime
The documentation mentions manually pushing Docker images to the CI. The
preferred way is to use the proper GitHub action. This updates the
documentation.
---------
Co-authored-by: Will Hawkins <whh8b@obs.cr>
This uses the macro on record types and inline constexpr variables. The
tagged declarations are very likely to change in future versions of
libc++:
- __fields are internal types used to control the formatter's parse
functions which fields to expect. Newer formatters may add new fields.
For example the filesystem::path formatter accepted in the recent Tokyo
meeting added a new 'g' flag, which differs from the 'g' type.
- The Unicode tables. The number of entries in these table likely differ
between Unicode versions. The tables contain only a part of all Unicode
properties. Typically they are stored in a 32-bit entry where some bits
contain the properties and other bits the size of the range. Changes in
the Unicode or C++ algorithms may require more properties to be
available in C++. This may affect the number of bits available in the
range. If needed, other declarations get the macro. This is mainly a
first time to review this approach.
This was originally https://reviews.llvm.org/D143494 where a new macro
_LIBCPP_HIDE_FROM_ABI_TYPE was defined. Testing revealed the existing
macro _LIBCPP_HIDE_FROM_ABI could be used. The "parts" of the macro that
do not affect records are not harmful. Based on this information the
existing macro was used and additional documentation was written.
Clang modules take a significant compile time hit when pushing and
popping diagnostics. Since all the headers are marked as system headers
in the modulemap, we can simply disable this pushing and popping when
building with clang modules.
## Abstract
This pull request converts the `operator()` of all CPOs and niebloids
related to C++23 ranges to `static`.
## Motivation
In `libc++`, CPOs and niebloids are implemented as function objects.
Currently, the `operator()` for such a function object is a
`const`-qualified member function. This means that even if the function
object is has no data members, an extra register is used to pass in the
`this` pointer when calling `operator()`, unless the compiler can inline
the function call. Declaraing `operator()` as `static` would optimize
away the unnecessary `this` pointer passing for stateless function
objects, since there is no object instance state that needs to be
accessed.
## Reference
- [P1169R4: static `operator()`](https://wg21.link/P1169R4)
Implement [LWG3528](https://wg21.link/LWG3528).
Based on LWG3528(https://wg21.link/LWG3528) and
http://eel.is/c++draft/description#structure.requirements-9, the
standard allows to impose requirements, we constraint
`std::make_from_tuple` to make `std::make_from_tuple` SFINAE friendly
and also avoid worse diagnostic messages. We still keep the constraints
of `std::__make_from_tuple_impl` so that `std::__make_from_tuple_impl`
will have the same advantages when used alone.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
Fixes#75975.
Remove `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` for the LLVM 19
release, it was previously marked as deprecated in LLVM 18.
I believe that
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` was only
used by Google in conjunction with
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS`.
Removing both macros together should not cause any issues in practice,
even though we did not announce the removal of
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` before.
This reapplies 272d1b44efdedb68c194970a610f0ca1b7b769c5 (from #85756),
which was reverted in
407937036fa7640f61f225474b1ea6623a40dbdd.
In the previous attempt, empty CMAKE_INSTALL_PREFIX was handled by
quoting them, in d209d1340b99d4fbd325dffb5e13b757ab8264ea. That made the
calls to cmake_path(ABSOLUTE_PATH) succeed, but the output paths of that
weren't actually absolute, which was required by file(RELATIVE_PATH).
Avoid this issue by constructing a non-empty base directory variable
to use for calculating the relative path.
`copy_n` has been used to allow constant evaluation of `char_traits`. We
now have `__constexpr_memmove`, which `copy_n` just forwards to. We can
call `__constexpr_memmove` directly, avoiding a bunch of instantiations.
This reduces the time it takes to include `<string>` from 321ms to
285ms.
This reverts commit 272d1b44efdedb68c194970a610f0ca1b7b769c5,
and the follow-up fix in d209d1340b99d4fbd325dffb5e13b757ab8264ea.
Even after the follow-up fix, building with an empty
CMAKE_INSTALL_PREFIX errors out with errors like this:
CMake Error at /b/s/w/ir/x/w/llvm-llvm-project/libcxx/modules/CMakeLists.txt:215 (file):
file RELATIVE_PATH must be passed a full path to the directory:
lib/x86_64-pc-windows-msvc
These were disabled due to ODR violations with mixed versions of
clang-tidy and the clang libraries. This issue was fixed in
e19e8600cf743690e1a23fb8a2b0dfbe2dafe559.
This reverts commit 0bbada93a559b604797fe57978f3eca5e41edaeb.
## Abstract
This pull request removes the `__workaround_52970` concept. This concept
is a workaround for a bug described in #52970, which causes the compiler
to trigger ADL on a pointer to an incomplete type in an SFINAE context.
This bug is fixed in Clang 14.
## Reference
- [[clang] Don't typo-fix an expression in a SFINAE
context](https://reviews.llvm.org/D117603)
- [[libc++] [ranges] ADL-proof the [range.access]
CPOs.](https://reviews.llvm.org/D116239)
## Abstract
This pull request implements LWG3715: `view_interface::empty` is
overconstrained. Here is an example similar to those described in the
report, which compiles with `-stdlib=libstdc++` but failed to compile
with `-stdlib=libc++`:
```cpp
// https://godbolt.org/z/EWEoTzah3
std::istringstream input("1 2 3 4 5");
auto i = std::views::istream<int>(input);
auto r = std::views::counted(i.begin(), 4) | std::views::take(2);
assert(!r.empty());
```
## Reference
- [Draft C++ Standard:
[view.interface.general]](https://eel.is/c++draft/view.interface.general)
- [LWG3715](https://wg21.link/LWG3715)
In other contexts, install directories such as
LIBCXX_INSTALL_LIBRARY_DIR and LIBCXX_INSTALL_MODULES_DIR can be
specified either as a relative path, relative to CMAKE_INSTALL_PREFIX,
or as an absolute path.
When calculating the relative path between the two, account for the fact
that LIBCXX_INSTALL_MODULES_DIR and LIBCXX_INSTALL_LIBRARY_DIR can be
absolute paths too.
This reverts commit 4109b18ee5de1346c2b89a5c89b86bae5c8631d3.
It looks like the automatic detection has false positives. This broke
the following build https://github.com/llvm/llvm-project/pull/85262
On Windows you can not create symlinks without elevated privileges
unless you have Windows developer mode enabled. There's ~67 libcxx tests
that run into failures on windows if your environment is not set up
correctly (Go to windows settings and enable "developer mode").
This change:
- Adds a feature check for whether the host can create symlinks. (see
libcxx/utils/libcxx/test/features.py)
- Mark the feature as required for the 67 tests that hit failures on
windows due to this. This will allow lit to correctly mark these tests
as unsupported instead of unexpectedly failed (this is helpful since
then you know you didn't break something with your change, it's just
that it's not supported with your environment).
These headers have become very small by using compiler builtins, often
containing only two declarations. This merges these headers, since
there doesn't seem to be much of a benefit keeping them separate.
Specifically, `is_{,_nothrow,_trivially}{assignable,constructible}` are
kept and the `copy`, `move` and `default` versions of these type traits
are moved in to the respective headers.
Since we implemented `copyable-box` in
(https://reviews.llvm.org/D102135,
6829db727e),
this issue got addressed.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
When calling setbuf(nullptr, 0) before performing file operations it
should set the file to unbuffered mode. Currently the code avoids
buffering internally, but the underlying stream still can buffer.
This is addressed by disabling the buffering of the underlying stream.
Fixes: https://github.com/llvm/llvm-project/issues/60509
27ce26b06655cfece3d54b30e442ef93d3e78ac7 added the new option
-fvisibility-global-new-delete=, where -fvisibility-global-new-delete=force-hidden
is equivalent to the old option -fvisibility-global-new-delete-hidden.
At the same time, the old option was deprecated.
Test for and use the new option form first; if unsupported, try
using the old form.
This avoids warnings in the MinGW builds, if built with Clang 18 or
newer.
