This avoids having to add `_LIBCPP_ENUM_VIS`, since that is handled through `type_visibility` and GCC always makes the visibility of enums default. It also fixes and missing `_LIBCPP_EXPORTED_FROM_ABI` on classes when using Clang.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D153658
The --mapping_file switch was missing; the example would have been
rejected.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D157785
The link syntax was missing a trailing underscore, and there was an
extraneous backtick on the reference to IWYU's libcxx.imp.
Reviewed By: #libc, philnik
Spies: Mordante, libcxx-commits
Differential Revision: https://reviews.llvm.org/D157784
In the event the internal function __init is called with an empty string the code will take unnecessary extra steps, in addition, the code generated might be overall greater because, to my understanding, when initializing a string with an empty `const char*` "" (like in this case), the compiler might be unable to deduce the string is indeed empty at compile time and more code is generated.
The goal of this patch is to make a new internal function that will accept just an error code skipping the empty string argument. It should skip the unnecessary steps and in the event `if (ec)` is `false`, it will return an empty string using the correct ctor, avoiding any extra code generation issues.
After the conversation about this patch matured in the libcxx channel on the LLVM Discord server, the patch was analyzed quickly with "Compiler Explorer" and other tools and it was discovered that it does indeed reduce the amount of code generated when using the latest stable clang version (16) which in turn produces faster code.
This patch targets LLVM 18 as it will break the ABI by addressing https://github.com/llvm/llvm-project/issues/63985
Benchmark tests run on other machines as well show in the best case, that the new version without the extra string as an argument performs 10 times faster.
On the buildkite CI run it shows the new code takes less CPU time as well.
In conclusion, the new code should also just appear cleaner because there are fewer checks to do when there is no message.
Reviewed By: #libc, philnik
Spies: emaste, nemanjai, philnik, libcxx-commits
Differential Revision: https://reviews.llvm.org/D155820
I need to use header_information.py in a generator script that isn't for tests in an upcoming change. Move it up a level so that it's in utils/libcxx instead of utils/libcxx/tests.
Differential Revision: https://reviews.llvm.org/D157639
This has been deprecated and should be removed now.
Reviewed By: #libc, Mordante
Spies: Mordante, libcxx-commits
Differential Revision: https://reviews.llvm.org/D157058
This implements P0009 std::mdspan ((https://wg21.link/p0009)),
a multidimensional span with customization points for
layouts and data access.
Co-authored-by: Damien L-G <dalg24@gmail.com>
Differential Revision: https://reviews.llvm.org/154367
Existing notes were not fully correct and were missing a detail:
- `std::vector` was annotated long time ago,
- `std::deque` annotations are new,
- now container annotations were extended to all allocators (support in ASan API exists since LLVM16).
Reviewed By: philnik, #libc
Differential Revision: https://reviews.llvm.org/D156162
Implements parts of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be
synchronized with the underlying stream?
Depends on D150044
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D155262
The headers that include_next compiler and OS headers need to be in different top level modules in order to avoid module cycles. e.g. libc++'s stdlib.h will #include_next stdlib.h from the compiler and then the C library. Either of those are likely to include stddef.h, which will come back up to the libc++ module map and create a module cycle. Putting stdlib.h and stddef.h (and the rest of the C standard library headers) in top level modules resolves this by letting the order go cxx_stdlib_h -> os_stdlib_h -> cxx_stddef_h -> os_stddef_h.
All of those headers' dependencies then need to be moved into top level modules themselves to avoid module cycles between the new top level level cstd modules. This starts to get complicated, as the libc++ C headers, by standard, have to include many of the C++ headers, which include the private detail headers, which are intertwined. e.g. some `__algorithm` headers include `__memory` headers and vice versa.
Make top level modules for all of the libc++ headers to easily guarantee that the modules aren't cyclic.
Add enough module exports to fix `check-cxx` and `run-buildbot generic-modules`.
`__stop_token/intrusive_shared_ptr.h` uses `__atomic/atomic.h` but has no include path to it. Add that include.
`math.h` absorbs `bits/atomic_wide_counter.h` on some platforms that don't have modules, work around that by including `math.h` in `__threading_support`.
<mutex> doesn't actually require threads, there are a few pieces like once_flag that work without threads. Remove the requirement from its module.
AIX is no longer able to support modular builds.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D144322
Drive-by fix to make sure the __retarget_buffer works correctly whan
using a hint of 1. This was discovered in one of the new tests.
Drive-by fixes __retarget_buffer when initialized with size 1.
Implements parts of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be
synchronized with the underlying stream?
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D150044
This way, we don't need to remove the contents of the ReleaseNotes file
after the branch. This should make it much easier and natural to cherry-pick
changes onto the release branch. Typically, we need two patches for those.
First, we need the code changes against `main`, and then we need a patch
that updates the release notes on the just-created branch.
By versioning the release notes, it becomes easy to author a change
against `main` that targets a just-branched LLVM release by simply
adding it to the release notes for the right version. This has been
a pain point in previous releases.
Differential Revision: https://reviews.llvm.org/D155024
This is a preparation for the upcoming LLVM 17 release.
Reviewed By: ldionne, jloser, H-G-Hristov, #libc
Differential Revision: https://reviews.llvm.org/D154874
Our threading support layer is currently a huge mess. There are too many
configurations with too many confusing names, and none of them are tested
in the usual CI. Here's a list of names related to these configurations:
LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY
_LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL
LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
LIBCXX_HAS_EXTERNAL_THREAD_API
_LIBCPP_HAS_THREAD_API_EXTERNAL
This patch cleans this up by removing the ability to build libc++ with
an "external" threading library for testing purposes, removing 4 out of
6 "names" above. That setting was meant to be used by libc++ developers,
but we don't use it in-tree and it's not part of our CI.
I know the ability to use an external threading API is used by some folks
out-of-tree, and this patch doesn't change that. This only changes the
way they will have to test their external threading support. After this
patch, the intent would be for them to set `-DLIBCXX_HAS_EXTERNAL_THREAD_API=ON`
when building the library, and to provide their usual `<__external_threading>`
header when they are testing the library. This can be done easily now
that we support custom lit configuration files in test suites.
The motivation for this patch is that our threading support layer is
basically unmaintainable -- anything beyond adding a new "backend" in
the slot designed for it requires incredible attention. The complexity
added by this setting just doesn't pull its weigh considering the
available alternatives.
Concretely, this will also allow future patches to clean up
`<__threading_support>` significantly.
Differential Revision: https://reviews.llvm.org/D154466
`_LIBCPP_ENABLE_ASSERTIONS` was used to enable the "safe" mode in
libc++. Libc++ now provides the hardened mode and the debug mode that
replace the safe mode.
For backward compatibility, enabling `_LIBCPP_ENABLE_ASSERTIONS` now
enables the hardened mode. Note that the hardened mode provides
a narrower set of checks than the previous "safe" mode (only
security-critical checks that are performant enough to be used in
production).
Differential Revision: https://reviews.llvm.org/D154997
This commit implements default_accessor in support of C++23 mdspan
(https://wg21.link/p0009). default_accessor is the trivial accessor
using plain pointers and reference to element types.
Co-authored-by: Damien L-G <dalg24@gmail.com>
Differential Revision: https://reviews.llvm.org/D153935
This patch only adds new configuration knobs -- the actual assertions
will be added in follow-up patches.
Differential Revision: https://reviews.llvm.org/D153902
This makes <__threading_support> closer to handling only the bridge
between the system's implementation of threading and the rest of libc++.
Differential Revision: https://reviews.llvm.org/D154464
Note libc++ implemented this in its initial version. It always used the type
from the C library and never validated whether it was an integer type.
Implements
- LWG3905 Type of std::fexcept_t
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D153285
Note libc++ actually implemented this wording from the start (D49338).
The Clang version is the same as the version that implements
P0122R7 <span>
Implements
- LWG3903 span destructor is redundantly noexcept
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D153284
