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
The post-condition on the functions is that the buffer is not full.
This post-conditon is used as pre-condition of the push_back function.
When a copy, fill, of transform function exactly fit in the buffer this
post-condition was validated.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D155397
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
<__format/format_functions.h> was using <string>, we need to bring the include back that was removed in D154122.
Reviewed By: Mordante, #libc
Differential Revision: https://reviews.llvm.org/D155116
Based on the review comments in D153201 this combines the string and
c-string constructors. The common constructor is using a string_view:
- it allows propagating the _Traits, which are required to be used for
comparison.
- it avoids allocating
- libc++ supports it in C++03
Reviewed By: philnik, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D154860
Adding assertions will aid users that have bugs in their code to receive better error messages.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D154626
@EricWF spotted this issue in the post-commit review comments of
D134742. However the suggestion to just use chrono calculations can
result in similar issues when using small fractional seconds.
Reviewed By: EricWF, #libc
Differential Revision: https://reviews.llvm.org/D138826
The output of
template<class charT, class traits>
basic_ostream<charT, traits>&
operator<<(basic_ostream<charT, traits>& out, thread::id id);
is affected by the state of out. The wording states
[thread.thread.id]/2
The text representation for the character type charT of an object of
type thread::id is an unspecified sequence of charT such that, for two
objects of type thread::id x and y, if x == y is true, the thread::id
objects have the same text representation, and if x != y is true, the
thread::id objects have distinct text representations.
[thread.thread.id]/9
template<class charT, class traits>
basic_ostream<charT, traits>&
operator<< (basic_ostream<charT, traits>& out, thread::id id);
Effects: Inserts the text representation for charT of id into out.
This wording changed in C++23 due to adding a formatter specialization for
thread::id. However the requirement was the same in older versions of C++.
This issue is that thread::id is an integral or pointer and affected by the
formatting manipulators for them. Thus the text representation can differ if
x == y which violates the requirements.
The fix has to hard-code some formatting style for the text
representation. It uses the Standard specified default values
Table 124: basic_ios::init() effects [tab:basic.ios.cons] flags()
flags() skipws | dec
Fixes PR: https://llvm.org/PR62073
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D153336
This commit deprecates `std::basic_string::__grow_by`, which is part of ABIv1. The function is replaced by `std::basic_string:__grow_by_without_replace`, which is not part of ABI.
- The original function `__grow_by` is deprecated because it does not set the string size, therefore it may not update the size when the size is changed, and it may also not set the size at all when the string was short initially. This leads to unpredictable size value. It is not removed or changed to avoid breaking the ABI.
- The commit adds `_LIBCPP_HIDE_FROM_ABI` guarded by `_LIBCPP_ABI_VERSION >= 2` to `__grow_by`. This allows the function to be used in the dylib in ABIv1 without raising the `[abi:v170000]` error and removes it from future ABIs. `_LIBCPP_HIDE_FROM_ABI_AFTER_V1` cannot be used.
- Additionally, `__grow_by` has been removed from `_LIBCPP_STRING_UNSTABLE_EXTERN_TEMPLATE_LIST` in `libcxx/include/__string/extern_template_lists.h`.
This bugfix is necessary to implement string ASan annotations, because it mitigates the problems encountered in D132769.
Reviewed By: ldionne, #libc, philnik
Differential Revision: https://reviews.llvm.org/D148693
`_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
While these tests do pass in the CI environment, they fail elsewhere.
On GitHub Action runners, they produce '+0000' instead of '-0000' for
the UTC offset, and on local machines, it outputs the UTC offset of
the local timezone.
Differential Revision: https://reviews.llvm.org/D155182
Remove spaces between operator"" and identifier to suppress
-Wdeprecated-literal-operator, and between operator and ""
like how they are written in [string.view.literals] and [basic.string.literals].
Differential Revision: https://reviews.llvm.org/D155200
This patch moves a few tests that were still using std::fprintf to
using TEST_REQUIRE instead, which provides a single point to tweak
for platforms that don't implement fprintf. As a fly-by fix, it also
avoids including `time_utils.h` in filesystem_clock.cpp when it is
not required, since that header makes some pretty large assumptions
about the platform it is on.
Differential Revision: https://reviews.llvm.org/D155019
This patch partly reverts the change that was made in 5f1ba3a502
regarding the clock selection on Apple platforms. It turns out that
gettimeofday() is marked as obsolete by POSIX and clock_gettime() is
recommended instead. Since both are equivalent for our purposes,
prefer using clock_gettime() even on Apple platforms.
Differential Revision: https://reviews.llvm.org/D155022
Currently, there are no tests to confirm without a doubt the constructor of latch is really constexpr and explicit.
I think this would be an addition that it would not harm to have. In another revision, I was asked to add tests for an almost identical case which made me consider adding this test for the latch class too.
Reviewed By: #libc, philnik
Spies: philnik, libcxx-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D154957
If I read the standard correctly, the public constructor of "barrier" should be marked as "constexpr explicit".
I see some of the internal classes used by the barrier header are correctly marked but I think, if I'm not mistaken, the standard would like the public class to have the correct definition as well.
Because the implementation that llvm uses by default is not constexpr friendly at this time, this revision will focus on only marking it as explicit.
Reviewed By: #libc, philnik, Mordante
Spies: philnik, Mordante, libcxx-commits
Differential Revision: https://reviews.llvm.org/D154590
The oldest deployment target supported by Xcode 14 is macOS 10.13.
Trying to back-deploy to older targets runs into other issues in Clang,
so stop testing libc++ against unsupported deployment targets.
This patch doesn't attempt to clean up support for older deployment
targets from the code base -- this will be done in a follow-up patch.
Differential Revision: https://reviews.llvm.org/D155085
This simply moves existing CI-related scripts for Clang outside of libc++
to make the two projects independent with respect to CI.
The reason for making this change is that libc++'s CI pipeline history
was full of Clang runs, making it a lot harder to figure out information
about libc++'s own jobs. I created a pipeline for Clang and this patch
will run pre-commit CI for Clang inside that pipeline instead.
Differential Revision: https://reviews.llvm.org/D155078
It's no longer necessary to define `_DEBUG` because we use our own
internal assertion mechanism in libc++.
Differential Revision: https://reviews.llvm.org/D155038
This patch only adds new configuration knobs -- the actual assertions
will be added in follow-up patches.
Differential Revision: https://reviews.llvm.org/D153902
When inserting nodes into a forward list, each new node is allocated but
not constructed. The constructor was being called explicitly on the node
`value_` but the `next_` pointer remained uninitialized rather than
being set to null. This bug is only triggered in the cleanup code if an
exception is thrown -- upon successful creation of new nodes, the last
incorrect "next" value is overwritten to a correct pointer.
This issue was found due to new tests added in
https://reviews.llvm.org/D149830.
Differential Revision: https://reviews.llvm.org/D152327
This moves the formatting job to a shell script, which should also fix
the clang pre-commit CI.
Differential Revision: https://reviews.llvm.org/D153920
This is a preparation for
P2093R14 Formatted output
When the output of print is to the terminal it needs to use the native
API. This means transcoding UTF-8 to UTF-16 on Windows. The encoder's
interface is modeled after
P2728 Unicode in the Library, Part 1: UTF Transcoding
But only the required part for P2093R14 is implemented.
On Windows wchar_t is 16 bits, in order to test on platforms where
wchar_t is 32 bits the transcoder has support for char16_t. It also adds
and UTF-8 to UTF-32 encoder which is useful for other tests.
Note it is possible to use <codecvt> for transcoding, but that header is
deprecated. So rather write new code that is not deprecated; the hard
part, decoding, has already been done. The <codecvt> header also
requires locale support while the new code works without including
<locale>.
Note the current transcoder implementation can be optimized since it
basically does UTF-8 -> UTF-32 -> UTF-16. The first goal is to have a
working implementation. Since it's not part of the ABI it's possible to
do the optimization later.
Depends on D149672
Reviewed By: ldionne, tahonermann, #libc
Differential Revision: https://reviews.llvm.org/D150031
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
There are discussions about different ways of implementing `stop_token` to make it more performant
mark `stop_token` as experimental to allow us to change the design before it is shipped
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Differential Revision: https://reviews.llvm.org/D154700
This should reduce the size of the transitive includes for the vector header.
Note the header still quite large so the difference may be small.
Depends on D154122
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D154286
As reported in https://reviews.llvm.org/D151953#4472195, the std::move
algorithm (and various other functions that relied on it) stopped working
after starting to use `__constexpr_memmove` in its implementation. This
patch fixes the underlying issue in `__constexpr_memmove` and adds tests
for various related algorithms and functions that were not exercising
trivial move-only types.
Differential Revision: https://reviews.llvm.org/D154613
MSVC is set for actual msvc and clang-cl. LIBXX_TARGETTING_CLANG_CL is
still used over in runtimes to configure warning flags.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D154698
When using the following constructors:
```
locale(const locale& other, const char* std_name, category cat);
locale(const locale& other, const string& std_name, category cat);
locale(const locale& other, const locale& one, category cats);
```
The new locale name is always "*". Locale names formed from parts of two named locales (that is, C++ locales having names) are supposed to have names in turn (see C++20 subclause 28.3.1.1 [locale.general] paragraph 8). This patch fixes the name construction for cases when either of locales are unnamed, when the category is locale::none, and when the two locale names are the same.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D119441
The first issue was found by @ldionne, upon further investigation there
were more duplicates. This removes the duplicates and updates the
clang-tidy test to detect duplicates.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D154723
