This changes the implementation of the formatter. Instead of inheriting
from a specialized parser all formatters will use the same generic
parser. This reduces the binary size.
The new parser contains some additional fields only used in the chrono
formatting. Since this doesn't change the size of the parser the fields
are in the generic parser. The parser is designed to fit in 128-bit,
making it cheap to pass by value.
The new format function is a const member function. This isn't required
by the Standard yet, but it will be after LWG-3636 is accepted.
Additionally P2286 adds a formattable concept which requires the member
function to be const qualified in C++23. This paper is likely to be
accepted in the 2022 July plenary.
This is based on D125606. That commit did the groundwork and did similar
changes for the string formatters.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128785
Instead of marking private symbols with internal_linkage (which leads to
one copy per translation unit -- rather wasteful), use an ABI tag that
gets rev'd with each libc++ version. That way, we know that we can't have
name collisions between implementation-detail functions across libc++
versions, so we'll never violate the ODR. However, within a single program,
each symbol still has a proper name with external linkage, which means
that the linker is free to deduplicate symbols even across TUs.
This actually means that we can guarantee that versions of libc++ can
be mixed within the same program without ever having to take a code size
hit, and without having to manually opt-in -- it should just work out of
the box.
Differential Revision: https://reviews.llvm.org/D127444
After checking the libc++abi.dylib shipped in macOS 10.13, I can confirm
that it contains the align_val_t variants of operator new and operator
delete. However, the libc++abi.dylib shipped on macOS 10.12 does not.
Differential Revision: https://reviews.llvm.org/D129198
The number of spaces between `#` and `pragma` can differ due to
different indention levels in the preprocessor directives. Therefore
allow any number of spaces.
The test used to put an exclamation mark in its diagnostic. This adds
little benefit and only makes it harder to copy the offending filename.
As drive-by this exclamation mark has been removed.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D129047
This way we ensure that we don't use-after-move the iterators.
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D129044
Both clang and GCC support using `__has_builtin` for detecting compiler-provided type_traits. Use it instead of `__has_keyword` or `__has_feature` to remove special-casing for GCC-provided builtins
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D129056
Display 'static_assert failed: message' instead of
'static_assert failed "message"' to be consistent
with other implementations and be slightly more
readable.
Reviewed By: #libc, aaron.ballman, philnik, Mordante
Differential Revision: https://reviews.llvm.org/D128844
This changes the implementation of the formatter. Instead of inheriting
from a specialized parser all formatters will use the same generic
parser. This reduces the binary size.
The new parser contains some additional fields only used in the chrono
formatting. Since this doesn't change the size of the parser the fields
are in the generic parser. The parser is designed to fit in 128-bit,
making it cheap to pass by value.
The new format function is a const member function. This isn't required
by the Standard yet, but it will be after LWG-3636 is accepted.
Additionally P2286 adds a formattable concept which requires the member
function to be const qualified in C++23. This paper is likely to be
accepted in the 2022 July plenary.
This is based on D125606. That commit did the groundwork and did similar
changes for the string formatters.
Depends on D128139.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128671
This changes the implementation of the formatter. Instead of inheriting
from a specialized parser all formatters will use the same generic
parser. This reduces the binary size.
The new parser contains some additional fields only used in the chrono
formatting. Since this doesn't change the size of the parser the fields
are in the generic parser. The parser is designed to fit in 128-bit,
making it cheap to pass by value.
The new format function is a const member function. This isn't required
by the Standard yet, but it will be after LWG-3636 is accepted.
Additionally P2286 adds a formattable concept which requires the member
function to be const qualified in C++23. This paper is likely to be
accepted in the 2022 July plenary.
This is based on D125606. That commit did the groundwork and did similar
changes for the string formatters.
Depends on D125606
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128139
Otherwise, this breaks freestanding builds, where `main()` isn't mangled
specially and we need to assume that we have a `int main(int, char**)`
entry point in each test for things to work.
- P1252 ("Ranges Design Cleanup") -- deprecate
`move_iterator::operator->` starting from C++20; add range comparisons
to the `<functional>` synopsis. This restores
`move_iterator::operator->` that was incorrectly deleted in D117656;
it's still defined in the latest draft, see
http://eel.is/c++draft/depr.move.iter.elem. Note that changes to
`*_result` types from 6.1 in the paper are no longer relevant now that
these types are aliases;
- P2106 ("Alternative wording for GB315 and GB316") -- add a few
`*_result` types to the synopsis in `<algorithm>` (some algorithms are
not implemented yet and thus some of the proposal still cannot be
marked as done);
Also mark already done issues as done (or as nothing to do):
- P2091 ("Fixing Issues With Range Access CPOs") was already implemented
(this patch adds tests for some ill-formed cases);
- LWG 3247 ("`ranges::iter_move` should perform ADL-only lookup of
`iter_move`") was already implemented;
- LWG 3300 ("Non-array ssize overload is underconstrained") doesn't
affect the implementation;
- LWG 3335 ("Resolve C++20 NB comments US 273 and GB 274") was already
implemented;
- LWG 3355 ("The memory algorithms should support move-only input
iterators introduced by P1207") was already implemented (except for
testing).
Differential Revision: https://reviews.llvm.org/D126053
This commit re-adds transitive includes that had been removed by
4cd04d1687, c36870c8e7, a83f4b9cda, 1458458b55, 2e2f3158c6,
and 489637e66d. This should cover almost all the includes that had
been removed since LLVM 14 and that would contribute to breaking user
code when releasing LLVM 15.
It is possible to disable the inclusion of these headers by defining
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will
enable that macro and start fixing downstream issues immediately. We
can then remove the macro (and the transitive includes) by default in
a future release. That way, we will break users only once by removing
transitive includes in bulk instead of doing it bit by bit a every
release, which is more disruptive for users.
Note 1: The set of headers to re-add was found by re-generating the
transitive include test on a checkout of release/14.x, which
provided the list of all transitive includes we used to provide.
Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map>
have been added in this commit. These transitive inclusions were
added when we implemented boyer_moore_searcher in <functional>.
Note 3: This is a best effort patch to try and resolve downstream breakage
caused since branching LLVM 14. I wasn't able to perfectly mirror
transitive includes in LLVM 14 for a few headers, so I added a
release note explaining it. To summarize, adding boyer_moore_searcher
created a bunch of circular dependencies, so we have to break
backwards compatibility in a few cases.
Differential Revision: https://reviews.llvm.org/D128661
Summary:
This patch ports libc++ LIT test cases for getting time in various locales to AIX.
Reviewed by: philnik, Mordante, libc++
Differential Revision: https://reviews.llvm.org/D128087
Summary:
This patch ports libc++ LIT test cases for money formats to AIX. On AIX, the money format of locale zh_CN.UTF-8 is the similar to that of en_US.UTF-8, i.e., sign, symbol, none, value.
Reviewed by: Mordante, DiggerLin, libc++
Differential Revision: https://reviews.llvm.org/D128220
Also, improve the test for nasty macros to define min and max, so this
will be caught in the future.
Differential Revision: https://reviews.llvm.org/D128655
It turns out that the Docker images on CI instances are not updated
based on what's in this file, but instead when a new image is pushed
to ldionne/libcxx-builder on DockerHub. So this is effectively useless.
Previously, we'd use raw pointers when the debug mode was enabled,
which means we wouldn't get out-of-range checking with std::span's
iterators.
This patch introduces a new class called __bounded_iter which can
be used to wrap iterators and make them carry around bounds-related
information. This allows iterators to assert when they are dereferenced
outside of their bounds.
As a fly-by change, this commit removes the _LIBCPP_ABI_SPAN_POINTER_ITERATORS
knob. Indeed, not using a raw pointer as the iterator type is useful to
avoid users depending on properties of raw pointers in their code.
This is an alternative to D127401.
Differential Revision: https://reviews.llvm.org/D127418
Summary:
Patch D123580 changed to use bit fields for strings in long and short mode. As a result, this changes the layout of these strings on AIX because bit fields on AIX are 4 bytes, which breaks the ABI compatibility with earlier strings before the change on AIX. This patch uses the attribute 'packed' and anonymous structure to make string layout compatible. This patch will also make test cases alignof.compile.pass.cpp and sizeof.compile.pass.cpp introduced in D127672 pass on AIX.
Reviewed by: philnik, Mordante, hubert.reinterpretcast, libc++
Differential Revision: https://reviews.llvm.org/D128285
1. for constructors that takes cvref variation of tuple<UTypes...>, there
used to be two SFINAE helper _EnableCopyFromOtherTuple,
_EnableMoveFromOtherTuple. And the implementations of these two helpers
seem to slightly differ from the spec. But now, we need 4 variations.
Instead of adding another two, this change refactored it to a single one
_EnableCtrFromUTypesTuple, which directly maps to the spec without
changing the C++11 behaviour. However, we need the helper __copy_cvref_t
to get the type of std::get<i>(cvref tuple<Utypes...>) for different
cvref, so I made __copy_cvref_t to be available in C++11.
2. for constructors that takes variations of std::pair, there used to be
four helpers _EnableExplicitCopyFromPair, _EnableImplicitCopyFromPair,
_EnableImplicitMoveFromPair, _EnableExplicitMoveFromPair. Instead of
adding another four, this change refactored into two helper
_EnableCtrFromPair and _BothImplicitlyConvertible. This also removes the
need to use _nat
3. for const member assignment operator, since the requirement is very
simple, I haven't refactored the old code but instead directly adding
the new c++23 code.
4. for const swap, I pretty much copy pasted the non-const version to make
these overloads look consistent
5. while doing these change, I found two of the old constructors wasn't
marked constexpr for C++20 but they should. fixed them and added unit
tests
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D116621
When merging the changes of <type_traits> header with the commits on
this header over the last month, several conflicts were mistaken
resolved and the wrong branch was picked while resolving conflicts,
which leads to CI failure. In order to resolve the conflicts properly
with qualification CI job, this change is reverted.
This reverts commit 95733a55b9.
1. for constructors that takes cvref variation of tuple<UTypes...>, there
used to be two SFINAE helper _EnableCopyFromOtherTuple,
_EnableMoveFromOtherTuple. And the implementations of these two helpers
seem to slightly differ from the spec. But now, we need 4 variations.
Instead of adding another two, this change refactored it to a single one
_EnableCtrFromUTypesTuple, which directly maps to the spec without
changing the C++11 behaviour. However, we need the helper __copy_cvref_t
to get the type of std::get<i>(cvref tuple<Utypes...>) for different
cvref, so I made __copy_cvref_t to be available in C++11.
2. for constructors that takes variations of std::pair, there used to be
four helpers _EnableExplicitCopyFromPair, _EnableImplicitCopyFromPair,
_EnableImplicitMoveFromPair, _EnableExplicitMoveFromPair. Instead of
adding another four, this change refactored into two helper
_EnableCtrFromPair and _BothImplicitlyConvertible. This also removes the
need to use _nat
3. for const member assignment operator, since the requirement is very
simple, I haven't refactored the old code but instead directly adding
the new c++23 code.
4. for const swap, I pretty much copy pasted the non-const version to make
these overloads look consistent
5. while doing these change, I found two of the old constructors wasn't
marked constexpr for C++20 but they should. fixed them and added unit
tests
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D116621
A situation that happens fairly often in libc++ is that we remove some
transitive includes in a header (either purposefully or not) and that
ends up breaking users. Of course, we want to be able to remove our
transitive includes, however it's also good to have a grip on that
to know which commit changed what and when. Furthermore, it's good
to accumulate include removals for a couple of releases to avoid
breaking users at every release for this reason.
This commit adds a test that should break whenever we remove an
include. Hence, it should allow us to track which headers include
which other headers transitively, giving us a traceable way to
remove headers.
Differential Revision: https://reviews.llvm.org/D128236
This is a helper patch to ease the reviewing of D128139.
The originals will be removed at a later time when all formatters are
converted to the new style. (Floating-point and pointer aren't up for
review yet.)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128367
This patch also adds a new optimization to `std::move`. It unwraps three `reverse_iterator`s if the wrapped iterator is a `contiguous_iterator` and the iterated type is trivially_movable. This allows us to simplify `ranges::move_backward` to a forward to `std::move` without any pessimization.
Reviewed By: var-const, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D126616
`__GCC_CONSTRUCTIVE_SIZE` and `__GCC_DESTRUCTIVE_SIZE` are available since GCC 12. I'm assuming clang will also implement these for compatability with libstdc++.
Reviewed By: ldionne, #libc
Spies: h-vetinari, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D122276
This is a follow up based on a request of @jloser in D127594.
As drive-by qualified the function calls in the <bit> header.
Reviewed By: #libc, EricWF
Differential Revision: https://reviews.llvm.org/D127760
Instead of instantiating all functions called by std::to_chars for the
integral types only instantiate them for 32 and 64 bit integral types.
This results in a smaller binary when using different types.
In an example using the types: signed char, short, int, long, long long,
unsigned char, unsigned short, unsigned int, unsigned long, and
unsigned long long this saved 2792 bytes of code size. For libc++.so.1
is saves 688 bytes of code size (64-bit Linux).
This was discovered while investigating a solution for #52709.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128215
For an lvalue reference to a move only view x, views::all(x) gives hard error because the expression inside noexcept is not well formed and it is not SFINAE friendly.
Given a move only view type `V`, and a concept
```
template <class R>
concept can_all = requires {
std::views::all(std::declval<R>());
};
```
The expression `can_all<V&>` returns
libstdc++: false
msvc stl : false
libc++ : error: static_cast from 'V' to 'typename decay<decltype((std::forward<V &>(__t)))>::type' (aka 'V') uses deleted function
noexcept(noexcept(_LIBCPP_AUTO_CAST(std::forward<_Tp>(__t))))
The standard spec has its own problem, the spec says it is expression equivalent to `decay-copy(E)` but the spec of `decay-copy` does not have any constraint, which means the expression `decay-copy(declval<V&>())` is well-formed and the concept `can_all<V&>` should return true and should error when instantiating the function body of decay-copy. This is clearly wrong behaviour in the spec and we will probably create an LWG issue. But the libc++'s behaviour is clearly not correct. The `noexcept` is an "extension" in libc++ which is not in the spec, but the expression inside `noexpect` triggers hard error, which is not right.
Reviewed By: #libc, ldionne, var-const
Differential Revision: https://reviews.llvm.org/D128281
`std::function` has been deprecated for a few releases now. Remove it with an option to opt-back-in with a note that this option will be removed in LLVM 16.
Reviewed By: ldionne, #libc
Spies: #libc_vendors, EricWF, jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D127908
This changes the implementation of the formatter. Instead of inheriting
from a specialized parser all formatters will use the same generic
parser. This reduces the binary size.
The new parser contains some additional fields only used in the chrono
formatting. Since this doesn't change the size of the parser the fields
are in the generic parser. The parser is designed to fit in 128-bit,
making it cheap to pass by value.
The new format function is a const member function. This isn't required
by the Standard yet, but it will be after LWG-3636 is accepted.
Additionally P2286 adds a formattable concept which requires the member
function to be const qualified in C++23. This paper is likely to be
accepted in the 2022 July plenary.
Depends on D121530
NOTE parts of the code now contains duplicates for the current and new parser.
The intention is to remove the duplication in followup patches. A general
overview of the final code is available in D124620. That review however lacks a
bit of polish.
Most of the new code is based on the same algorithms used in the current code.
The final version of this code reduces the binary size by 17 KB for this example
code
```
int main() {
{
std::string_view sv{"hello world"};
std::format("{}{}|{}{}{}{}{}{}|{}{}{}{}{}{}|{}{}{}|{}{}|{}", true, '*',
(signed char)(42), (short)(42), (int)(42), (long)(42), (long long)(42), (__int128_t)(42),
(unsigned char)(42), (unsigned short)(42), (unsigned int)(42), (unsigned long)(42),
(unsigned long long)(42), (__uint128_t)(42),
(float)(42), (double)(42), (long double)(42),
"hello world", sv,
nullptr);
}
{
std::wstring_view sv{L"hello world"};
std::format(L"{}{}|{}{}{}{}{}{}|{}{}{}{}{}{}|{}{}{}|{}{}|{}", true, L'*',
(signed char)(42), (short)(42), (int)(42), (long)(42), (long long)(42), (__int128_t)(42),
(unsigned char)(42), (unsigned short)(42), (unsigned int)(42), (unsigned long)(42),
(unsigned long long)(42), (__uint128_t)(42),
(float)(42), (double)(42), (long double)(42),
L"hello world", sv,
nullptr);
}
}
```
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D125606
A formatter using a handle only needs to satisfy the BasicFormatter
requirements. The current test allowed more than that minimum. Changed
it to the minimum to make sure it works.
This was due to a post-commit review comment of @vitaut in D121530.
Reviewed By: ldionne, vitaut, #libc
Differential Revision: https://reviews.llvm.org/D127767
This makes Clang scream at us if there is a class without a key function.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D127900
The optimization level used when building the benchmarks should
match the optimization level of the current build. Otherwise, we
can end up mixing an -O3 or -O0 optimized dylib with benchmarks
built with -O2, which is really misleading.
Differential Revision: https://reviews.llvm.org/D127987
This mostly copys the `<experimental/functional>` stuff and updates the code to current libc++ style.
Reviewed By: ldionne, #libc
Spies: nlopes, adamdebreceni, arichardson, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D121074
Simplify the implementation of `std::copy` and `std::move` by using `__unwrap_iter` and `__rewrap_iter` to unwrap and rewrap `reverse_iterator<reverse_iterator<Iter>>` instead of specializing `__copy_impl` and `__move_impl`.
Reviewed By: ldionne, #libc
Spies: wenlei, libcxx-commits
Differential Revision: https://reviews.llvm.org/D127049
Simplify logic in `__config` by assuming that we are using Clang in C++03 mode. Also, use standardized feature-test macros instead of compiler-specific checks (like `__has_feature`) in a couple of places.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D127606
When compiled with `-D_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS`
uses of `allocator<void>::pointer` resulted in compiler errors after D104323.
If we instantiate the primary template, `allocator<void>::reference` produces
an error 'cannot form references to void'.
To workaround this, allow to bring back the `allocator<void>` specialization by defining the new `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` macro.
To make sure the code that uses `allocator<void>` and the removed members does not break,
both `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` and `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` have to be defined.
Reviewed By: ldionne, #libc, philnik
Differential Revision: https://reviews.llvm.org/D126210
We decided that we want to use clang-format for libc++ but we haven't decided yet how the code should be formatted. We should probably discuss things on discord. This PR is mostly to show how the clang-format would look like and to commit to one once we decided on it. I'll remove the `<string>` diff when I commit this PR.
Reviewed By: ldionne
Spies: EricWF, dschuff, krytarowski, fedor.sergeev, aheejin, mstorsjo, phosek, abrachet, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D124789
For reference, this test creates about 1.5G in the cache
directory. By default this will go to ~/.cache/clang/
which can fill up quick. This changes the test to put the
cache path in lit temp directories. Size considerations
aside it makes sense for tests to be hermetic and not
touch global system state.
Differential revision: https://reviews.llvm.org/D127587
The existing nm extractors can't dump the loader symbol table information we need to do the ABI checks for XCOFF, so provide an implementation using the system dump utility. We match the symbol name, whether it's defined, it's import/export status, and its storage mapping class.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D124165
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
This patch switches the build compiler for AIX from ibm-clang to clang. ibm-clang++_r has `-pthread` by default, but clang for AIX doesn't, so `-pthread` had to be added to the test config. A bunch of tests now pass, so the `XFAIL` was removed. This patch also switch the build to use the visibility support available in clang-15 to control symbols exported by the shared library (AIX traditionally uses explicit export lists for this purpose).
Reviewed By: #libc, #libc_abi, daltenty, #libunwind, ldionne
Differential Revision: https://reviews.llvm.org/D127470
All supported compilers have concepts support so use that in the C++20
functions in <bit>.
s/_LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI/ as drive-by fix.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D127594
This removes all "TODO: remove these headers" comments from our headers.
Note there seem to be more headers that can be removed, that will be
done in separate commits.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D127592
The compilers clang-11, clang-12, and apple-clang-12 are no longer
supported, so remove their annotations in the tests.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D127588
Instead of trying to be clever and design our own locking primitive,
simply rely on the OS-provided implementation to do the right thing.
Indeed, manually yielding to the OS does not provide the necessary
information for it to make good prioritization decisions. For example,
if a thread with higher priority yields while waiting for a lock held
by a thread with lower priority but the system is contended, it is
possible for the thread with lower priority to not run until the higher
priority thread has yielded 16 times and goes for __libcpp_mutex_lock().
Once that happens, the OS can bump the priority of the thread that
currently holds the lock to unblock everyone. So instead, we might as
well give the system all the information from the start so it can make
appropriate decisions.
As a fly-by change, also increase the number of locks in the table.
The size increase is modest, but has the potential to half the amount
of contention on those locks.
rdar://93598606
Differential Revision: https://reviews.llvm.org/D126882
D125496 changed the string layout on windows. Change `__is_long_` and `__size_` back to using `unsigned char` to fix the issue.
Reviewed By: Mordante, #libc
Spies: jloser, libcxx-commits, ayzhao
Differential Revision: https://reviews.llvm.org/D127566
There is only compile-time tests in `dtor.pass.cpp`, so it could be made a
`dtor.compile.pass.cpp`. Instead, add a runtime test for testing the trivial
destructor behavior for `tuple`.
Differential Revision: https://reviews.llvm.org/D109298
The tests for `std::ranges::lazy_split_view` heavily use a wrapper class around
`std::string` because `std::string` was not `constexpr` until recently. Where
possible, remove the wrapper class and extra functionality no longer needed.
Remove `libcxx/test/std/ranges/range.adaptors/range.lazy.split/small_string.h`
and inline its one use remaining in
`libcxx/test/std/ranges/range.adaptors/range.lazy.split/general.pass.cpp`.
Differential Revision: https://reviews.llvm.org/D126663
include the invalid LIBCXX_ABI_NAMESPACE to ease debugging.
Reviewed By: #libc, jloser, ldionne
Differential Revision: https://reviews.llvm.org/D127257
- Updates the image to use Ubuntu Jammy.
- Installs GCC-12 as preparation to migrate to that GCC version.
NOTE: This is a re-application of f2f0dba818, which was reverted
in 2b5e3ef83c due to an issue with the CI nodes. The CI nodes have
since then been updated and this appears to be fine.
Differential Revision: https://reviews.llvm.org/D126666
The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for
slightly different configurations (like the debug mode or assertions
in the dylib) are taken into account. That results in unexpected bugs
like http://llvm.org/PR50534 (and there have been multiple similar
bugs in the past, notably around the debug mode).
This patch gets rid of the _LIBCPP_DISABLE_EXTERN_TEMPLATE knob, which
I don't think is fundamental. Indeed, the motivation for that knob was to
avoid taking a dependency on the library, however that can be done better
by linking against the static library instead. And in fact, some parts of
the headers will always depend on things defined in the library, which
defeats the original goal of _LIBCPP_DISABLE_EXTERN_TEMPLATE.
Differential Revision: https://reviews.llvm.org/D103960
When some headers are not available because we removed features like
localization or threads, the compiler should not try to include these
headers when building modules. To avoid that from happening, add a
requires-declaration that is never satisfied when the configuration
in use doesn't support a header.
rdar://93777687
Differential Revision: https://reviews.llvm.org/D127127
This reverts commit f2f0dba818.
This Docker file doesn't work on the CI. It fails to clone the checkout.
This seems like an issue with a newer glibc on an older Docker where the
clone3() call fails.
This needs further investigation before relanding.
Get rid of the __is_trivially_copy_assignable_unwrapped helper, which
is only used in one place, and use __iter_value_type instead of
iterator_traits<T>::value_type.
Differential Revision: https://reviews.llvm.org/D127230
With the new version of Git in Ubuntu Jammy (which is now what we use in
our Docker image), we need to add `/llvm` to the list of safe directories
to avoid failures.
The debug mode has been broken pretty much ever since it was shipped
because it was possible to enable the debug mode in user code without
actually enabling it in the dylib, leading to ODR violations that
caused various kinds of failures.
This commit makes the debug mode a knob that is configured when
building the library and which can't be changed afterwards. This is
less flexible for users, however it will actually work as intended
and it will allow us, in the future, to add various kinds of checks
that do not assume the same ABI as the normal library. Furthermore,
this will make the debug mode more robust, which means that vendors
might be more tempted to support it properly, which hasn't been the
case with the current debug mode.
This patch shouldn't break any user code, except folks who are building
against a library that doesn't have the debug mode enabled and who try
to enable the debug mode in their code. Such users will get a compile-time
error explaining that this configuration isn't supported anymore.
In the future, we should further increase the granularity of the debug
mode checks so that we can cherry-pick which checks to enable, like we
do for unspecified behavior randomization.
Differential Revision: https://reviews.llvm.org/D122941
After moving the std::to_chars base 10 implementation from the dylib to
the header the integral overloads of std::to_chars are available on all
platforms.
Remove the _LIBCPP_AVAILABILITY_TO_CHARS availability macro and update
the tests.
Depends on D125704
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D125745
- Updates the image to use Ubuntu Jammy.
- Installs GCC-12 as preparation to migrate to that GCC version.
Reviewed By: ldionne, #libc, jloser
Differential Revision: https://reviews.llvm.org/D126666
This was noticed in the review of D125704. In that commit only the new
table has been adapted. This adapts the existing tables.
Note since libc++'s charconv is backported to C++11 it's not possible to
use inline constexpr variables. The were introduced in C++17.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D126887
In MinGW environments, thanks to slightly different code generation
and linker tricks, it's possible to link against a DLL C++ standard
library without dllimport attributes.
This allows using one single set of headers for linking against
either the DLL or a static library, leaving the decision entirely
up to the linking stage (where it can be switched with options like
-static-libstdc++).
This matches how libstdc++ headers work; there's no dllimport attributes
by default (unless the user has defined _GLIBCXX_DLL when including
headers).
This allows using one single set of headers while linking against
either a DLL or a static library, just like on Unix platforms.
This matches how libc++ has been used in MinGW configurations for
years (by first building the DLL, then configuring a static-only
build and installing on top, overwriting the libc++ config file
with one for static linking) by multiple MinGW toolchains, making
the dllimport-less use the de-facto tested configuration in the wild.
This also allows building all of libc++ in one single CMake
configuration, instead of having to do two separate builds on top of
each other.
(Linking against a DLL without dllimport can break if e.g. templates
use inconsistent visibility attributes - in cases where it still
works when using explicit dllimport; such a case was fixed in
948dd664c3 / D99932. With this as the
default configuration, we can catch such issues in CI.)
Differential Revision: https://reviews.llvm.org/D125924
In clang-cl/MSVC environments, linking against a DLL C++ standard
library requires having dllimport attributes in the headers; this
has been used for detecting whether the tests link against a DLL,
by looking at the libc++ specific define
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS.
In mingw environments, thanks to slightly different code generation
and a couple linker tricks, it's possible to link against a DLL C++
standard library without dllimport attributes. Therefore, don't
rely on the libc++ specific header define for the detection.
Replace the detection with a runtime test.
Differential Revision: https://reviews.llvm.org/D125922
Currently, unary expressions involving valarray will create a temporary.
This leads to dangling references in expressions like `-a * b`, because
`-a` is a temporary and the resulting expression will refer to it. This
patch fixes the problem by creating a lazy expression to perform the unary
operation instead of eagerly creating a temporary valarray. This is
permitted by the Standard, which does not specify the exact type of
most expressions involving valarrays.
This is technically an ABI break, however I believe the actual potential
for breakage is very low.
rdar://90152242
Differential Revision: https://reviews.llvm.org/D125019
Instead of providing two different constructors for iterators that
support the debug mode, provide a single constructor but leave the
container parameter unused when the debug mode is not enabled.
This allows simplifying all the call sites to unconditionally pass
the container, which removes a bunch of duplication in the container's
implementation.
Note that this patch does add some complexity to std::span, however
that is only because std::span has the ability to use raw pointers
as iterators instead of __wrap_iter. In retrospect, I believe it was
a mistake to provide that capability, and so it will be removed in a
future patch, along with the complexity added by this patch.
Differential Revision: https://reviews.llvm.org/D126993
The `ranges.transform.pass.cpp` often times out on CI for AIX (32-bit and 64-bit)
only. Mark the test as `UNSUPPORTED` for `AIX` for now. It should be looked into in
the future.
Differential Revision: https://reviews.llvm.org/D127051
`string_view` is supported all the way back to C++03 as an extension in
`libc++`, and so many of the tests run in all standards modes for all vendors.
This is unlikely desired by other standard library vendors using our test suite.
So, disable the tests for vendors other than `libc++` in these older standards
modes.
Differential Revision: https://reviews.llvm.org/D126850
In D122982 I accidentally disabled the memmove optimization. This re-enables it and adds more cases where copy forwards to memmove.
Fixes https://github.com/llvm/llvm-project/issues/33687
Reviewed By: var-const, #libc, ldionne
Spies: pkasting, ayzhao, dcheng, xbolva00, libcxx-commits
Differential Revision: https://reviews.llvm.org/D124328
In 6423a9f0ec, I accidentally thought this was
getting tested, but these variables are unused. Just remove the lines instead of
leaving them commented out.
Differential Revision: https://reviews.llvm.org/D126901
Small typo fix(es) for struct definition of __optional_storage_base for
a reference type.
Reviewed By: #libc, jloser, philnik
Differential Revision: https://reviews.llvm.org/D126621
This removes the duplicated code from the dylib. Instead the dylib will
call the new functions in the header. Since this code is unneeded it's
removed from the unstable ABI.
Depends on D125704
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D125761
Some test cases for `ends_with.ptr.pass` and `starts_with.ptr.pass` for
`string_view` are commented out, but work just fine. Uncomment them.
Differential Revision: https://reviews.llvm.org/D126849
Summary:
This patch changes scripts to add libunwind CI on AIX. Test config file ibm-libunwind-shared.cfg.in is introduced for testing on AIX.
Reviewed by: ldionne, MaskRay, libunwind, ibc++abi
Differential Revision: https://reviews.llvm.org/D126017
The functions to_chars and from_chars should offer 128-bit support. This
is the first step to implement 128-bit version of to_chars. Before
implementing 128-bit support the current code will be polished.
This moves the code from the dylib to the header in prepartion of
P2291 "Add Constexpr Modifiers to Functions to_chars and from_chars for
Integral Types in <charconv> Header"
Note some more cleanups will be done in follow-up commits
- Remove the _LIBCPP_AVAILABILITY_TO_CHARS from to_chars. With all code
in the header the availablilty macro is no longer needed. This
requires enabling the unit tests for additional platforms.
- The code in the dylib can switch to using the header implementation.
This allows removing the code duplicated in the header and the dylib.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D125704
Some tests in `string.view.comparison` are not enabled due to previous lack of
support for `constexpr std::string`. Now that it is implemented, we can enable
these tests.
Differential Revision: https://reviews.llvm.org/D126737
Formatting a string-literal had an off-by-one issue where the NUL
terminator became part of the formatted output.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D126665
The machine hosting these agents will be down
for maintenance June 2nd.
We (Linaro) will remove this once the agents are back online.
Differential Revision: https://reviews.llvm.org/D126688
P0798R8 "Monadic operations for std::optional" has been implemented, so
this LWG issue can be adopted.
During review it was discovered another paper bumped the macro. The
part affecting optional of this paper is done, the variant isn't. The
status page is updated to reflect the current state.
Implements
- LWG 3621 Remove feature-test macro __cpp_lib_monadic_optional
Updates status of
- P2231R1 Missing constexpr in std::optional and std::variant
Reviewed By: #libc, philnik, ldionne
Differential Revision: https://reviews.llvm.org/D125813
Clang 3.7 and below is not actively used or supported in the test suite now, so
remove the workaround in the test.
Differential Revision: https://reviews.llvm.org/D126603
Since those features are general properties of the environment, it makes
sense to use them from libc++abi too, and so the name libcpp-has-no-xxx
doesn't make sense.
Differential Revision: https://reviews.llvm.org/D126482
Add a warning and tweak the release note to explain that the deprecation
targets libc++, libc++abi and libuwnind as well.
Also, as a fly-by, ensure that our CI runs the legacy testing configuration
for libc++, libc++abi and libunwind. This doesn't matter too much since
it's deprecated, but we might as well test it properly.
Differential Revision: https://reviews.llvm.org/D126478
Those were spotted when a project unintentionally started exporting
these symbols from its ABI just by using the libc++ headers.
Differential Revision: https://reviews.llvm.org/D126496
While looking at D113413 I noticed that __log2i could perhaps be
improved to be both slightly smaller and faster.
projects/libcxx/benchmarks/sort.libcxx.out --benchmark_filter=BM_Sort_uint32_QuickSortAdversary*
suggests this is performance neutral, but it shaves a few bytes off the
benchmark binary, and even more off a Chromium build.
Differential revision: https://reviews.llvm.org/D125958
Start testing Apple backdeployment with older libunwinds, and stop
explicitly specifying the libunwind testing config, since it is
already selected correctly by default.
Differential Revision: https://reviews.llvm.org/D126470
Uncomment the tests to ensure `std::ranges::rbegin` and friends are indeed
customization points objects.
Differential Revision: https://reviews.llvm.org/D126325
Once we move off entirely from the legacy testing framework, this will
allow removing a bunch of code.
Differential Revision: https://reviews.llvm.org/D126303
This commit ensures that we can include all libc++ headers with modules
enabled. It adds a test to ensure that this doesn't regress, which is
necessary because our modules CI job does not build in all Standard modes.
Differential Revision: https://reviews.llvm.org/D125331
Abseil benchmarks suggest that the conditional checks result in faster code (4-5x)
as they are compiled into conditional move instructions (cmov on x86).
Reviewed By: #libc, philnik, Mordante
Spies: pengfei, Mordante, philnik, libcxx-commits
Differential Revision: https://reviews.llvm.org/D125329
This fixes incorrect handling of non-moveable types, adding tests for this case.
See [issue 55346](https://github.com/llvm/llvm-project/issues/55346).
The current implementation is based on is_convertible, which is
[defined](https://timsong-cpp.github.io/cppwp/n4659/meta.rel#5) in terms of
validity of the following function:
```
To test() {
return declval<From>();
}
```
But this doesn't work if To and From are both some non-moveable type, which the
[definition](https://timsong-cpp.github.io/cppwp/n4659/conv#3) of implicit
conversions says should work due to guaranteed copy elision:
```
To to = E; // E has type From
```
It is this latter definition that is used in the
[definition](https://timsong-cpp.github.io/cppwp/n4659/function.objects#func.require-2)
of INVOKE<R>. Make __invokable_r use __is_core_convertible, which
captures the ability to use guaranteed copy elision, making the
definition correct for non-moveable types.
Fixesllvm/llvm-project#55346.
Reviewed By: #libc, philnik, EricWF
Spies: EricWF, jloser, ldionne, philnik, libcxx-commits
Differential Revision: https://reviews.llvm.org/D125300
This is essentially a revert of c7ad02009. Indeed, it seems that both
96dbdd75 and c7ad02009 were committed, but c7ad02009 seems to be only
an older version of 96dbdd75's tests.
We use `auto` in C++03, so we shouldn't say that we aren't.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D126165
All compilers that libc++ supports support `push_macro` and `pop_macro`. So let's remove it.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D126073
`<type_traits>` is quite a large header, so I'll granularize it in a few steps.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D124755
We should not surface CMake-level options like LIBCXX_ENABLE_FILESYSTEM
to our users, since they don't know what it means. Instead, use a slightly
more general wording.
Also, add an error in <ios> to improve the quality of errors for people
trying to use <iostream> when localization is disabled.
Differential Revision: https://reviews.llvm.org/D125910
Also, add a CI job that tests this configuration. The exact configuration
is that we build a shared libc++ and merge objects for the ABI library
and the unwinder library into it.
Differential Revision: https://reviews.llvm.org/D125903
We require move semantics in C++03 anyways, so let's enable them for the containers.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D123802
Summary:
fixed a return curr_symbol() for Russian in the libcxx/test/support/locale_helpers.h for AIX
Reviewers: David Tenty,Mark de Wever
Differential Revision: https://reviews.llvm.org/D125801
Use a specialized buffer wrapper to limit the number of insertions in the
buffer. After the limit has been reached the buffer only needs to count
the number of insertions to return the buffer size required to store the
entire output.
Depends on D110498
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D110499
This optimizes the __format_arg_store type to allow a more efficient
storage of the basic_format_args.
It stores the data in two arrays:
- A struct with the tag of the exposition only variant's type and the
offset of the element in the data array. Since this array only depends
on the type information it's calculated at compile time and can be
shared by different instances of this class.
- The arguments converted to the types used in the exposition only
variant of basic_format_arg. This means the packed data can be
directly copied to an element of this variant.
The new code uses rvalue reference arguments in preparation for P2418.
The handle class also has some changes to prepare for P2418. The real
changed for P2418 will be done separately, but these parts make it
easier to implement that paper.
Some parts of existing test code are removed since they were no longer
valid after the changes, but new tests have been added.
Implements parts of:
- P2418 Add support for std::generator-like types to std::format
Completes:
- LWG3473 Normative encouragement in non-normative note
Depends on D121138
Reviewed By: #libc, vitaut, Mordante
Differential Revision: https://reviews.llvm.org/D121514
This formatter isn't in the list of required formatters in
[format.formatter.spec]/2.2
For each charT, the string type specializations
template<> struct formatter<charT*, charT>;
template<> struct formatter<const charT*, charT>;
template<size_t N> struct formatter<const charT[N], charT>;
template<class traits, class Allocator>
struct formatter<basic_string<charT, traits, Allocator>, charT>;
template<class traits>
struct formatter<basic_string_view<charT, traits>, charT>;
Since remove_cvref_t<const charT[N]> is charT[N] the formatter is
required by
[format.functions]/25
Preconditions: formatter<remove_cvref_t<Ti>, charT> meets the
BasicFormatter requirements ([formatter.requirements]) for each Ti in
Args.
Depends on D120921
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D121138
The concept is based on P2286R2 Formatting Ranges. It will be used to
optimise the storage of __format_arg_store as required by LWG-3473.
Depends on D120916
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D120921
(In the case of libunwind, the cmake option is called
LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as
LIBCXX_HERMETIC_STATIC_LIBRARY and
LIBCXXABI_HERMETIC_STATIC_LIBRARY.)
Previously, the same issue was dealt with by setting a project wide
define (_LIBUNWIND_HIDE_SYMBOLS,
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static
library. If building both static and shared at the same time, this
wasn't set, and the static library would contain dllexport directives.
The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake
options only apply the defines to the static library in the build,
even if building both static and shared at the same time.
(This could only be done use after the object libraries were
enabled, as a shared libcxx needs libcxxabi object files built
with dllexports included.)
This allows removing inelegant code for deciding how to build the
libcxxabi static library and a TODO comment that suggested that
users should need to start setting an option, which they shouldn't
need to. Finally, this gets rid of two XFAILs in tests.
Differential Revision: https://reviews.llvm.org/D125715
As mentionned in D97044, it is fine if users include <atomic> and then
include <stdatomic.h> -- we don't need to error out for that case.
Differential Revision: https://reviews.llvm.org/D125579
I think this notion of libc++abi's version was relevant a long time ago
on Apple platforms when we were using a Xcode project to build the library.
As part of moving Apple's build to CMake, D59489 made it possible to
specify the "ABI version" of libc++abi in use. However, it's not possible
to build libc++abi with that old ABI anymore and we don't need the ability
to link against that version from libc++ anymore.
Hence, we can clean this up and stop falsely pretending that libc++abi
has more than one ABI version.
Differential Revision: https://reviews.llvm.org/D125687
This is a variant of D116689 rebased on top of the new (proposed) ABI
refactoring in D120727. It should conserve the basic properties of the
original patch by @phosek, except it also allows cleaning up the merging
of libc++abi into libc++ from the libc++ side.
Differential Revision: https://reviews.llvm.org/D125393
`std::views::drops` and `std::views::join` have been implemented, but the tests
verifying the CPOs for them are still commented out. Uncomment the tests.
Differential Revision: https://reviews.llvm.org/D125618
Quite a few C++20 LWG issues/papers related to the One Ranges Proposal
were already effectively implemented (or contain semantic-only wording
changes that don't affect the implementation), mark them as such.
Differential Revision: https://reviews.llvm.org/D125065
This simplifies the string structs a bit more and the normal layout should not contain any undefined behaviour anymore. I don't think there is a way to achieve this in the alternate string mode without breaking the ABI.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D125496
For example, we used to trigger CI even for commits that touched a file
whose path contained 'cmake', even if it's not the root cmake directory.
Fix that.
Standalone builds have been deprecated and then removed for a while now.
Trying to use standalone builds leads to a fatal CMake error, so this
code is all dead. Remove it to clean things up.
Differential Revision: https://reviews.llvm.org/D125561
This patch overhauls how we pick up the ABI library. Instead of setting
ad-hoc flags, it creates interface targets that can be linked against by
the rest of the build, which is easier to follow and extend to support
new ABI libraries.
This is intended to be a NFC change, however there are some additional
simplifications and improvements we can make in the future that would
require a slight behavior change.
Differential Revision: https://reviews.llvm.org/D120727
We add `--unwindlib=none` to `CMAKE_REQUIRED_FLAGS`
to make sure that builds with a yet-incomplete toolchain succeed,
to avoid linker failures about missing unwindlib.
When this option is added to `CMAKE_REQUIRED_FLAGS`, it gets added to
both compile and link commands in CMake compile tests. If
`--unwindlib=none` is included in compilation commands, it causes
warnings about unused arguments, as the flag only is relevant for
linking.
Due to the warnings in CMake tests, the later CMake test for the
`-Werror` option failed (as the tested `-Werror` option caused the
preexisting warning due to unused `--unwindlib=none` to become a
hard error). Therefore, most CI configurations that build with
`LIBCXX_ENABLE_WERROR` didn't actually end up enabling `-Werror`
after all.
When looking at the CI build log of recent CI builds, they do
end up printing:
-- Performing Test LIBCXX_SUPPORTS_WERROR_FLAG
-- Performing Test LIBCXX_SUPPORTS_WERROR_FLAG - Failed
-- Performing Test LIBCXX_SUPPORTS_WX_FLAG
-- Performing Test LIBCXX_SUPPORTS_WX_FLAG - Failed
Thus while the configurations are meant to error out on warnings,
they actually haven't done that, due to the interaction of these
options.
To fix this, remove the individual cases of adding `--unwindlib=none`
into `CMAKE_REQUIRED_FLAGS` in libcxx and libunwind.
`runtimes/CMakeLists.txt` still adds `--unwindlib=none` if needed, but
not otherwise. (The same issue with enabling `-Werror` does remain
if `--unwindlib=none` strictly is needed though - that can be fixed
separately afterwards.)
These individual cases in libunwind and libcxx were added while
standalone builds of the runtimes still were supported - but no longer
are necessary now.
Differential Revision: https://reviews.llvm.org/D124375
I guess this is an ABI break for the 32 bit AIX configuration, but I'm
not sure if that one is meant to be ABI stable yet or not.
Previously, this used int32_t for this type on linux, but int64_t
on all other platforms. This was added in D68480 /
54fa9ecd30, but I don't really see
any discussion around this detail there.
Switching this to 32 bit on 32 bit AIX silences these libcxx build
warnings:
```
In file included from /scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/libcxx/src/atomic.cpp:12:
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1005:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:948:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_load(const_cast<__ptr_type>(&__a->__a_value), static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1000:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1022:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_sub(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
4 warnings generated.
```
Differential Revision: https://reviews.llvm.org/D124519
This isn't a configuration that we unfortunately can add to
the CI practically at the moment, but I do run the tests
sporadically offline in this configuration.
Differential Revision: https://reviews.llvm.org/D124993
After feedback from D122861, do the same thing with some of the other headers. Try to move the
headers so they have a similar style and way of doing things.
Reviewed By: ldionne, daltenty
Differential Revision: https://reviews.llvm.org/D124227
This only adds the customization point object (which isn't pipeable),
the view itself has already been implemented previously.
Differential Revision: https://reviews.llvm.org/D124978
[libcxx] Reject month 0 in get_date/__get_month
This fixes#47663.
Months in dates should be >= 1 and <= 12.
We parse up to two digits then minus one, because
we want to store this as "months since January"
(0-11).
However we didn't check that the result of that
was not -1. For example if you had (MM/DD/YYYY)
00/21/2022.
Added tests for:
* Failing if month is 0
* Failing if month is 13
* Allowing a leading zero in month e.g. "01"
Note that libc++ and libstdc++ return different
values on parsing failure, and MSVC STL returns
end of stream instead.
Handle the first two by checking for defines, MSVC STL
expects these tests to fail for other reasons already:
https://github.com/microsoft/STL/blob/main/tests/libcxx/expected_results.txt#L372
so not handling that case here.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D124175
On targets without unistd.h or sys/wait.h (such as bare metal targets)
any test that uses check_assertion.h will fail, so add
REQUIRES: has-unix-headers to them and autodetect whether we have
these headers or not.
These tests currently have unsupported on windows, but that's exactly
because windows doesn't have these headers so we can remove the
specific check for windows.
Differential Revision: https://reviews.llvm.org/D124623
Adding a mingw based config is easy in the current CI environment
(where we can just choose the different target by calling
`i686-w64-mingw32-clang`), while adding a clang-cl based config would
require setting up different environment variables pointing to the
i386 library directory.
Just adding one config (DLL) instead of exhaustively testing both
(DLL and static) as very few tests would differ in practice, to keep
the CI load reasonable.
Differential Revision: https://reviews.llvm.org/D124991
This test only fails on x86_64 clang-cl, not for i386.
(The root cause is still not explored, thus the FIXME is still
relevant.)
Differential Revision: https://reviews.llvm.org/D124994
All current Windows architectures (i386, x86_64, arm, arm64) get
the full_size() behaviour here. x86_64 (the only one tested in CI
currently) is handled by the first ifdef at the top, but handle
Windows in general on all other architectures later.
Differential Revision: https://reviews.llvm.org/D124989
There are many more instances of this pattern, but I chose to limit this change to .rst files (docs), anything in libcxx/include, and string literals. These have the highest chance of being seen by end users.
Reviewed By: #libc, Mordante, martong, ldionne
Differential Revision: https://reviews.llvm.org/D124708
Several helper functions specify preconditions as comments, but we never
check them. I ran across a bug report (without a reproducer) in this code,
and I thought that having these assertions in place would make it easier
to troubleshoot.
Differential Revision: https://reviews.llvm.org/D124477
Reorganize the test and simplify the #ifdefs. Fix a typo in __powerpc64__
as a fly-by, and also add a test for the unstable ABI.
Differential Revision: https://reviews.llvm.org/D124403
Replace all the instances of `_LIBCPP_INLINE_VISIBILITY` with `_LIBCPP_HIDE_FROM_ABI` and `_VSTD` with `std`.
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D124662
We are considering to make -fsanitize-memory-param-retval enabled by default so probably this patch is unnneded.
Reviewed By: #libc, EricWF
Differential Revision: https://reviews.llvm.org/D123979
The GCC failures were partly fixed in D124103.
The format functions tests are fixed on GCC but they require a huge
amount of RAM (>10 GB). This fails with parallel testing in the CI. It
can be solved by splitting the test, but GCC-12 will be released shortly
and might fix the memory usage in these tests. Therefore these tests
remain disabled.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D124335
Detected on many lld tests with -fsanitize-memory-use-after-dtor.
Also https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-fast after D122869 will report a lot of them.
Threads may outlive static variables. Even if ~__thread_specific_ptr() does nothing, lifetime of members ends with ~ and accessing the value is UB https://eel.is/c++draft/basic.life#1
```
==9214==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x557e1cec4539 in __libcpp_tls_set ../include/c++/v1/__threading_support:428:12
#1 0x557e1cec4539 in set_pointer ../include/c++/v1/thread:196:5
#2 0x557e1cec4539 in void* std::__msan::__thread_proxy<
std::__msan::tuple<...>, llvm::parallel::detail::(anonymous namespace)::ThreadPoolExecutor::ThreadPoolExecutor(llvm::ThreadPoolStrategy)::'lambda'()::operator()() const::'lambda'()> >(void*) ../include/c++/v1/thread:285:27
Memory was marked as uninitialized
#0 0x557e10a0759d in __sanitizer_dtor_callback compiler-rt/lib/msan/msan_interceptors.cpp:940:5
#1 0x557e1d8c478d in std::__msan::__thread_specific_ptr<std::__msan::__thread_struct>::~__thread_specific_ptr() libcxx/include/thread:188:1
#2 0x557e10a07dc0 in MSanCxaAtExitWrapper(void*) compiler-rt/lib/msan/msan_interceptors.cpp:1151:3
```
The test needs D123979 or -fsanitize-memory-param-retval enabled by default.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122864
from libcxx/test/std/input.output/string.streams/stringbuf/stringbuf.virtuals/
[NFC] As part of using inclusive language within the llvm project, this
patch rewords comments to remove sanity check.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D124391
On x86 long double is 80 bit with padding, which produces
uninitialized bits in the result.
This will trigger errors with -fsanitize-memory-param-retval.
Can be triggered with D123979.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D123980
- add zip_view and views::zip for C++23
- added unit tests
- implemented section 5.6 (zip) in P2321R2
I used clang-format to format the files but they look nothing like the rest of the code base. Manually indenting each line to match the styles sounds like an impossible task. Is there any clang-format file which can format it reasonable similar to the rest of the code base so that I can manually format the rest lines that look weird?
Reviewed By: ldionne, #libc, philnik, var-const
Spies: Mordante, philnik, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D122806
Avoid repeating CMake checks across runtimes by unifying names of
variables used for results to leverage CMake caching.
Differential Revision: https://reviews.llvm.org/D110005
D123182 fixes a bug in Clang's overload resolution. After it landed it
was discovered `basic_format_arg`'s constructors contains this bug. This
fixes the bug in libc++, unblocking D123182.
The code has been tested in combination with D123182.
Reviewed By: royjacobson, #libc
Differential Revision: https://reviews.llvm.org/D124103
`vector<bool>::const_reference` and `vector<bool>::const_iterator::reference` should be the same type.
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D123851
Summary:
1. there are 23 test cases which do not run because of locale fileset not install, after the locale installed, these test cases will be run and fail. "LIBCXX-AIX-FIXME" on the 23 test cases which remain to be investigated on AIX.
2.after installed the locale fileset ,
the test case
libcxx/test/std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp pass
remove XFAIL: LIBCXX-AIX-FIXME from the file
Reviewers: David Tenty
Differential Revision: https://reviews.llvm.org/D124174
This makes the code a bit simpler and (I think) removes the undefined behaviour from the normal string layout.
Reviewed By: ldionne, Mordante, #libc
Spies: labath, dblaikie, JDevlieghere, krytarowski, jgorbe, jingham, saugustine, arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D123580
- added views::join adaptor object
- added test for the adaptor object
- fixed some join_view's tests. e.g iter_swap test
- added some negative tests for join_view to test that operations do not exist when constraints aren't met
- added tests that locks down issues that were already addressed in previous change
- LWG3500 `join_view::iterator::operator->()` is bogus
- LWG3313 `join_view::iterator::operator--` is incorrectly constrained
- LWG3517 `join_view::iterator`'s `iter_swap` is underconstrained
- P2328R1 join_view should join all views of ranges
- fixed some issues in join_view and added tests
- LWG3535 `join_view::iterator::iterator_category` and `::iterator_concept` lie
- LWG3474 Nesting ``join_views`` is broken because of CTAD
- added tests for an LWG issue that isn't resolved in the standard yet, but the previous code has workaround.
- LWG3569 Inner iterator not default_initializable
Reviewed By: #libc, var-const
Spies: var-const, libcxx-commits
Differential Revision: https://reviews.llvm.org/D123466
This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`, `move_if_noexcept`, `as_const`, `addressof`, and the
libstdc++-specific function `__addressof`.
We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.
This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.
We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.
In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.
The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.
This is a re-commit of
fc30901096,
a571f82a50,
64c045e25b, and
de6ddaeef3,
and reverts aa643f455a.
This change also includes a workaround for users using libc++ 3.1 and
earlier (!!), as apparently happens on AIX, where std::move sometimes
returns by value.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D123345
Revert "Fixup D123950 to address revert of D123345"
This reverts commit aa643f455a.
functions are not treated as [[nodiscard]].
The compiler might choose to treat them as [[nodiscard]] without the
involvement of libc++ if we allow it to recognize them as builtins.
This makes it a little easier to reuse the libc++ tests for another
std::lib (specifically libstdc++).
The regex_error::what() strings are different in other
implementations, so should be tested with LIBCPP_ASSERT so that those
checks are skipped for other implementations.
The value of ECMAScript constant is non-zero in other implementations,
and conditionally for libc++, so adjust the preprocessor condition for
that too.
Reviewed By: ldionne, #libc, philnik, Mordante
Spies: Mordante, philnik, libcxx-commits
Differential Revision: https://reviews.llvm.org/D122574
Note that this class was called just `split_view` in the original One
Ranges Proposal and was renamed to `lazy_split_view` by
[P2210](https://wg21.link/p2210).
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
Differential Revision: https://reviews.llvm.org/D107500
When we build the library with the stable ABI, we need to include some
functions in the dylib that were made inline in later versions of the
library (to avoid breaking code that might be relying on those symbols).
However, those methods were made non-inline whenever we'd be building
the library, which means that all translation units would end up using
the old out-of-line definition of these methods, as opposed to the new
inlined version. This patch makes it so that only the translation units
that actually define the out-of-line methods use the old definition,
opening up potential optimization opportunities in other translation
units.
This should solve some of the issues encountered in D65667.
Differential Revision: https://reviews.llvm.org/D123519
In the C++20 Standard time is no longer section under utilities, but
became its own chapter. This moves the time tests accordingly so their
location matches the current Standard.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122745
If a single test has been running for more than 20 minutes on a CI node,
something is wrong and it should time-out instead of running until the
node potentially times out itself.
Differential Revision: https://reviews.llvm.org/D114896
The Android platform does not have ndk-version.h, but it will always
have up-to-date libc headers, so it does not need any compatibility
code intended for past versions of NDK_MAJOR. If ndk-version.h is missing,
assume NDK_MAJOR is (conceptually) infinite
Bug: https://buganizer.corp.google.com/issues/222341313
Test: None
On non-Windows platforms, get_temp_file_name() uses `mkstemp()`,
which picks a unique name and creates a file atomically. The
Windows implementation uses `_mktemp_s()`, which doesn't create the
file. The documentation of `_mktemp_s()` also says that by design,
the function uses the same pattern within a process, as long as that
file doesn't exist.
Thus previously, two consecutive calls to `get_temp_file_name()`
on Windows returned the same file name.
Try to create the suggested temp file with `_O_EXCL` (marking the
file name as already used for future calls to `_mktemp_s`) and retry
if we weren't able to exclusively create the file.
This fixes the test failures on Windows observed in D122257.
Differential Revision: https://reviews.llvm.org/D122612
This supersedes and incoroporates content from both D108906 and D54966,
and also some original content.
Co-Authored-by: Marshall Clow <mclow.lists@gmail.com>
Co-Authored-by: Gonzalo Brito Gadeschi
Differential Revision: https://reviews.llvm.org/D118938
Use a specialized "buffer" to count the number of insertions instead of
using a `string` as storage type.
Depends on D110497.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D110498
Instead of writing every character directly into the container by using
a `back_insert_iterator` the data is buffered in an `array`. This buffer
is then inserted to the container by calling its `insert` member function.
Since there's no guarantee every container's `insert` behaves properly
containers need to opt-in to this behaviour. The appropriate standard
containers opt-in to this behaviour.
This change improves the performance of the format functions that use a
`back_insert_iterator`.
Depends on D110495
Reviewed By: ldionne, vitaut, #libc
Differential Revision: https://reviews.llvm.org/D110497
This is to simplify the changes made in D122780. This diff was generated using the command:
```
clang-format include/__algorithm/sort.h -i
```
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D122858
This patch addresses a clash with the PS register from Xtensa
defined in the <specreg.h> header file, which is commonly included in
OS implementation.
Issue identified while building libc++ port for Apache NuttX, targeting
Xtensa-based chips (e.g. Espressif's ESP32).
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
Differential Revision: https://reviews.llvm.org/D122479
This change is done to see whether all platforms have a CI with the
Japanese locale installed.
This wires in the locale in the tests and uses it in one test. This is
a preparation for the tests of the chrono formatters.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122738
Adds a `__get_container` member as suggested by @Quuxplusone in D110497.
Includes s/_LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI/.
Reviewed By: Quuxplusone, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D110573
Before implementing P2216's format-string adjust the unit tests.
After P2216 the format* functions require a compile-time string literal.
This changes prepares the tests.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D122534
`__is_callable` is required to ensure that the classic algorithms are only called with functions or functors. I also begin to granularize `<type_traits>`.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D123114
We are introducing branchless variants for sort3, sort4 and sort5.
These sorting functions have been generated using Reinforcement
Learning and aim to replace __sort3, __sort4 and __sort5 variants
for integral types.
The libc++ benchmarks were run on isolated machines for Skylake, ARM and
AMD architectures and achieve statistically significant improvement in
sorting random integers on test cases from sort1 to sort262144 for
uint32 and uint64.
A full performance overview for Intel Skylake, AMD and Arm can be
found here: https://bit.ly/3AtesYf
Reviewed By: ldionne, #libc, philnik
Spies: daniel.mankowitz, mgrang, Quuxplusone, andreamichi, philnik, libcxx-commits, nilayvaish, kristof.beyls
Differential Revision: https://reviews.llvm.org/D118029
Introduce _LIBCPP_ASSERTIONS_DISABLE_ASSUME which makes _LIBCPP_ASSERT
not call __builtin_assume when _LIBCPP_ENABLE_ASSERTIONS == 0.
Calling __builtin_assume was introduced in D122397.
__builtin_assume is generally supposed to improve optimizations, but can
cause regressions when LLVM has trouble handling the calls to
`llvm.assume()` (see comments in D122397).
Reviewed By: philnik
Differential Revision: https://reviews.llvm.org/D123175
There are `constexpr` versions for the different `__invoke` functions, which seem to be identical other than begin `constexpr` since C++11 instead of being `constexpr` since C++20.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D123003
There are no such markings left - all of them have been fixed or
analyzed.
This closes llvm.org/PR32730 (github issue #32077).
Differential Revision: https://reviews.llvm.org/D123145
The is a followup of D116965 to split the calendar header. This is a
preparation to add the formatters for the chrono header.
The code is only moved no other changes have been made.
Reviewed By: ldionne, #libc, philnik
Differential Revision: https://reviews.llvm.org/D122995
This patch implements P0674R1, i.e. support for arrays in std::make_shared
and std::allocate_shared.
Co-authored-by: Zoe Carver <z.zoelec2@gmail.com>
Differential Revision: https://reviews.llvm.org/D62641
On Windows, like on macOS and FreeBSD, widening char(-5) in the
"C" locale succeeds and produces L'\u00fb'.
Switch widen_many to test \xfb instead of \x85; the mingw
version of btowc widens \x85 in the "C" locale into
\u2026 (which is the corresponding character according to the
Windows-1252 codepage), while Microsoft CRT's btowc widens it
into \u0085 (just like macOS and FreeBSD). Switch this to test \xfb
which is the character tested by the widen_1 test (as `char(-5)`),
which gets handled the same by all Windows implementations of btowc.
Differential Revision: https://reviews.llvm.org/D121003
[libc++] add global variable template std::views::empty
Note it is neither a range adaptor, nor a CPO. It is simplify a global variable template.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D122996
This iterator is used to test code that only needs to satisfy the
output_iterator concept. Follow-up changes will use this iterator in
older language Standards.
Reviewed By: ldionne, #libc, philnik, var-const
Differential Revision: https://reviews.llvm.org/D122072
Instead of using `.fail.cpp` tests, use `.verify.cpp` to check for the
exact reason of the failure. In the case of deduction guides, use SFINAE
based tests instead since that is our preferred way of testing those.
Finally, ensure that we actually run the test in `iter_alloc_deduction.pass.cpp`,
since we were not running anything before.
Differential Revision: https://reviews.llvm.org/D123055
Since a8d15a9266 / D110975, this is
the default, even if winpthread headers are available, so we don't
need to cargo cult setting this option in all builds.
Differential Revision: https://reviews.llvm.org/D122717
Note that `generate_assertion_tests.py` will be renamed to
`generate_header_tests.py` separately to facilitate change tracking.
Differential Revision: https://reviews.llvm.org/D123000
The pointer.volatile.pass.cpp test was already marked as XFAIL for
mingw-dll (for reasons explained in the comment above it).
The same issue also appears in clang-cl-dll when built with newer
CMake versions. (It didn't appear with older versions of CMake, as
CMake built the library with the clang-cl flag `-std:c++latest` when
we've requested C++ 20 - which practically built it in c++2b mode with
current clang versions. With current versions of CMake, it passes
`-std:c++20` instead.)
As it succeeds/fails dependent on factors we don't
directly control, mark it as UNSUPPORTED instead of XFAIL.
Differential Revision: https://reviews.llvm.org/D122718
Note of the functions was marked as _LIBCPP_HIDE_FROM_ABI.
Did some minor formatting fixes to keep consistency. To keep it easy to
review not all odd formatting has been fixed.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122834
The alternative outputs of std::put_time and std::strftime are the
easiest to test with the Japanese locale. This is a preparation for the
tests of the chrono formatters.
Note since it takes a while before the Docker file changes propagate to
the build nodes the verification of the locale is done in a separate
patch.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122736
Reduced the details of the non-chrono formatting information. This has
been shipped and these details part of P0645 which is still documented.
Removing this information keeps the information up-to-date.
Adds the formatters required for the types chrono namespace.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122735
It seems to have been added back in 761e42fa3d for Clang to use it,
however it seems to have never been used for that purpose, so it is
probably fine to remove it.
Differential Revision: https://reviews.llvm.org/D122330
For some reason, we've been going without a MSAN CI job, even though
even run-buildbot defined a generic-msan job. This must have been an
oversight that went unnoticed. Thanks to @EricWF for the catch.
Differential Revision: https://reviews.llvm.org/D120851
This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.
It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.
Differential Revision: https://reviews.llvm.org/D122506
This allows us to detect whether we're being compiled with LLVM's libunwind
more easily, without CMake having to set explicit variables.
As discussed in https://llvm.org/D119538.
Differential Revision: https://reviews.llvm.org/D121015
Since we expect the condition to be true most of the time, we might
as well tell the compiler. And when assertions are disabled, we
might as well tell the compiler that it's allowed to assume that
the condition holds.
Differential Revision: https://reviews.llvm.org/D122397
This means that re-running with llvm-lit in that configuration will
work as expected. This also enables assertions in libc++abi in the
Generic-assertions CI job, which was disabled previously.
Differential Revision: https://reviews.llvm.org/D122597
Instead of using a temporary `string` in `__vformat_to_wrapped` use a new
generic iterator. This aids to reduce the number of template instantions
and avoids using a `string` to buffer the entire formatted output.
This changes the type of `format_context` and `wformat_context`, this can
still be done since the code isn't ABI stable yet.
Several approaches have been evaluated:
- Using a __output_buffer base class with:
- a put function to store the buffer in its internal buffer
- a virtual flush function to copy the internal buffer to the output
- Using a `function` to forward the output operation to the output buffer,
much like the next method.
- Using a type erased function point to store the data in the buffer.
The last version resulted in the best performance. For some cases there's
still a loss of speed over the original method. This loss many becomes
apparent when large strings are copied to a pointer like iterator, before
the compiler optimized this using `memcpy`.
Reviewed By: ldionne, vitaut, #libc
Differential Revision: https://reviews.llvm.org/D110495
I suspect this is a remnant of the times when we were not comfortable
using Clang's C++11/14 extensions everywhere, but now we do, so we can
use _BoolConstant instead and get rid of the macro.
Differential Revision: https://reviews.llvm.org/D122351
In C++20 the type trait `type_identity` was introduced. For the same purpose there is `__identity` for pre-C++20 code. The name is confusing, because since C++20 there is also `identity`, which isn't a type trait.
Reviewed By: ldionne, Mordante, #libc
Spies: EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D122017
I audited all uses of _LIBCPP_ASSERT to make sure that we only used it
for "basic assertions", i.e. assertions with constant-time conditions.
I also audited all uses of _LIBCPP_DEBUG_ASSERT to make sure we used it
only for debug-mode assertions, and in one case had to change for
_LIBCPP_ASSERT instead.
As a fly-by, I also changed a couple of tests against nullptr or 0 to
be more explicit.
After this patch, all uses of _LIBCPP_ASSERT should be with constant-time
conditions, and all uses of _LIBCPP_DEBUG_ASSERT should be with conditions
that we only want to check when the debug mode is enabled.
Differential Revision: https://reviews.llvm.org/D122395
Add missing commit SHAs in a few cases, and use "All Platforms" when
the change affected all platforms instead of explicitly listing the
platforms, since there's too many to list exhaustively.
This patch adds a lightweight assertion handler mechanism that can be
overriden at link-time in a fashion similar to `operator new`.
This is a third take on https://llvm.org/D121123 (which allowed customizing
the assertion handler at compile-time), and https://llvm.org/D119969
(which allowed customizing the assertion handler at runtime only).
This approach is, I think, the best of all three explored approaches.
Indeed, replacing the assertion handler in user code is ergonomic,
yet we retain the ability to provide a custom assertion handler when
deploying to older platforms that don't have a default handler in
the dylib.
As-is, this patch provides a pretty good amount of backwards compatibility
with the previous debug mode:
- Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions
in their code will still get basic assertions out of the box, but
those assertions will be using the new assertion handler support.
- Code that was previously compiled with references to __libcpp_debug_function
and friends will work out-of-the-box, no changes required. This is
because we provide the same symbols in the dylib as we used to.
- Code that used to set a custom __libcpp_debug_function will stop
compiling, because we don't provide that declaration anymore. Users
will have to migrate to the new way of setting a custom assertion
handler, which is extremely easy. I suspect that pool of users is
very limited, so breaking them at compile-time is probably acceptable.
The main downside of this approach is that code being compiled with
assertions enabled but deploying to an older platform where the assertion
handler didn't exist yet will fail to compile. However users can easily
fix the problem by providing a custom assertion handler and defining
the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to
let the library know about the custom handler. In a way, this is
actually a feature because it avoids a load-time error that one would
otherwise get when trying to run the code on the older target.
Differential Revision: https://reviews.llvm.org/D121478
See https://reviews.llvm.org/D121626 for details -- this re-enables the
CTAD we removed, since it does break some stuff as well (even though it's
not nearly as bad as the removed constructors fixed by D121626).
Differential Revision: https://reviews.llvm.org/D122184
This patch makes it possible to pass a CMake option to one of the runtimes
for all targets being built. Basically, any option that starts with the
name of a runtime project being built will be forwarded as-is to the
sub-build. This is useful for customizing a sub-build for all targets.
Differential Revision: https://reviews.llvm.org/D121822
The test fails on AIX due to it expecting an error as on Linux. However, as on
other non-Linux systems symlinks permissions are supported so expect an empty
error code.
Reviewed By: daltenty, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D121140
It turns out that we had never been enabling it anyways, since the
LIBCXX_TEST_PARAMS parameter was not being passed from the bootstrapping
build to the libc++ and libc++abi builds. Furthermore, it looks like the
per-target include directories used by the bootstrapping build by default
are incompatible with our current modulemap, since __config_site doesn't
live in the directory that our modulemap claims.
This disables modules in our bootstrapping CI job to unblock D121822,
but we should work on fixing the underlying issue once we're able to
pass those configuration options to our bootstrapping build.
These are the last™ changes to the tests for constexpr preparation.
Reviewed By: Quuxplusone, #libc, Mordante
Spies: Mordante, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D120951
Before it only accepted one output iterator type. Now it accepts all
output iterator types as required by BasicFormatter.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D120916
Addresses LWG 3548 which mandates that when shared_ptr is being constructed from a unique_ptr, the unique_ptr's deleter should be moved and not copied.
Reviewed By: #libc, philnik, EricWF
Differential Revision: https://reviews.llvm.org/D119159
Changes in [P0896](https://wg21.link/p0896):
- add `disable_sized_sentinel_for`;
- add `iter_move` and `iter_swap`;
- add a `requires` clause to the `operator->`;
- add `iterator_concept`;
- check that the `Iterator` template parameter is a bidirectional
iterator;
- add constraints to all comparison operators;
- change the definitions of `iterator_category`, `value_type`,
`difference_type` and `reference` (changes to `iterator_category` were
already implemented).
Also add a few forgotten things to the `reverse_iterator` synopsis
(notably the spaceship operator).
Differential Revision: https://reviews.llvm.org/D120180
This tests the same QoI issue as the existing STL Classic test,
but for the Ranges algorithms. Also, do the same thing for all
the algorithms that take projections.
I found a few missing algorithms and added them to the existing test, too. `std::find_first_of` currently fails; I should look at why that is (and in particular, what is it doing weird that //makes// it inconsistent with the entire rest of libc++?).
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D121265
We've been meaning to remove support for the legacy testing configuration
for a long time. This patch switches the default from the legacy config
to the appropriate new-style configuration based on a few hints.
We've been running with the new-style configuration for more than a year
in our CI, however it's possible that this will uncover issues with some
users that run the tests on platforms that we don't support yet with the
new-style configs. Unfortunately, there is no way to know about it other
than to land this patch and see whether anything breaks.
Differential Revision: https://reviews.llvm.org/D121632
This reverts commit 406d418c0c.
Our regular bots are now using clang-13. The previous set will remain
online for a while to check reviews that haven't rebased to include
this change yet.
Differential Revision: https://reviews.llvm.org/D121894
In the new-style testing configurations, we were hardcoding paths to the
`include` and `lib` directories, which was incorrect but always went
unnoticed because the hardcoded values always happened to match the
actual value.
When using new-style configs with the bootstrapping build, this falls
appart -- and we never noticed this because the bootstrapping build was
still using old style configs.
This patch removes the %{install} substitution, which makes it too
tempting to hardcode installation paths, and it also switches the
bootstrapping build to actually using new-style configs like we
always intended to do.
Differential Revision: https://reviews.llvm.org/D121700
In 7fb40e1569, I changed the availability for bad_optional_access and
friends from macOS 10.14 to 10.13 after conducting an investigation on
old dylibs. It turns out that macOS 10.13 did have bad_optional_access,
however the dylib on iOS didn't match the dylib on macOS, so those
exception classes were only introduced in iOS 12.
Thanks to Aditya Kumar for noticing this.
Differential Revision: https://reviews.llvm.org/D121735
It's the role of the C++ ABI library to install its own headers, not libc++.
This fixes an existing issue causing spurious CI failures where both libc++
and libc++abi would try to install <cxxabi.h> & friends in the same location,
leading to failures during the installation step.
Differential Revision: https://reviews.llvm.org/D121706
This should make CI consistent on all the compilers we support. Most of
this patch is working around various warnings emitted by GCC in our code
base, which are now being shown when we compile the tests.
After this patch, the whole test suite should be warning free on all
compilers we support and test, except for a few warnings on GCC that
we silence explicitly until we figure out the proper fix for them.
Differential Revision: https://reviews.llvm.org/D120684
Back in 3a208c6894, we implemented the range-based constructor for <span>.
However, in doing so, we removed a previous non-standard constructor that
we provided before shipping <ranges>. Unfortunately, that breaks code that
was relying on a range-based constructor until we ship all of <ranges>.
This patch reintroduces the old non-conforming constructors and tests
that were removed in 3a208c6894 and uses them whenever <ranges> is
not provided (e.g. in LLVM 14). This is only a temporary workaround
until we enable <ranges> by default in C++20, which should hopefully
happen by LLVM 15.
The goal is to cherry-pick this workaround back to the LLVM 14 release
branch, since I suspect the constructor removal may otherwise cause
breakage out there, like the breakage I saw internally.
We could have avoided this situation by waiting for C++20 to be finalized
before shipping std::span. For example, we could have guarded it with
something like _LIBCPP_HAS_NO_INCOMPLETE_RANGES to prevent users from
accidentally starting to depend on it before it is stable. We did not
have these mechanisms when std::span was first implemented, though.
Differential Revision: https://reviews.llvm.org/D121626
The class `__dir_stream` is currently declared in two places: as a
top-level forward declaration in `directory_iterator.h`, and as a friend
declaration in class `directory_entry`, in `directory_entry.h`.
The former has a `_LIBCPP_HIDDEN` attribute, but the latter does not,
causing the Firefox build to complain about the visibility not matching
the previous declaration. This is because Firefox plays games with
pushing and popping visibility.
Work around this by making both `__dir_stream` declarations consistently
use `_LIBCPP_HIDDEN`.
Reviewed By: ldionne, philnik, #libc
Differential Revision: https://reviews.llvm.org/D121639
Prior to this patch, there was no distinction between tests that check
basic assertions and tests that check full-fledged iterator debugging
assertions. Both were disabled when support for the debug mode is not
provided in the dylib, which is stronger than it needs to be.
Furthermore, all of the tests using "debug_macros.h" that contain more
than one assertion in them were broken -- any code after the first
assertion would never be executed.
This patch refactors all of our assertion-related tests to:
1. Be enabled whenever they can, i.e. basic assertions tests are run
even when the debug mode is disabled.
2. Use the superior `check_assertion.h` (previously `debug_mode_helper.h`)
instead of `debug_macros.h`, which allows multiple assertions in the
same program.
3. Coalesce some tests into the same file to make them more readable.
4. Use consistent naming for test files -- no more db{1,2,3,...,10} tests.
This is a large but mostly mechanical patch.
Differential Revision: https://reviews.llvm.org/D121462
It turns out that the whole header is only enabled in C++20 and above,
so these checks were redundant (and always true).
Differential Revision: https://reviews.llvm.org/D121604
All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.
Differential Revision: https://reviews.llvm.org/D121528
We don't need preprocessor logic to exclude those declarations when compiling for
the Windows App Store, because that is handled by using_if_exists now.
Differential Revision: https://reviews.llvm.org/D108632
Instead of carrying around #ifdefs to determine whether those functions
are available on the platform, unconditionally use the using_if_exists
attribute to import it into namespace std only when available. That was
the purpose of this attribute from the start.
This change means that trying to use libc++ with an old SDK (or on an
old platform for platforms that ship system headers in /usr/include)
will require a recent Clang that supports the using_if_exists attribute.
When using an older Clang or GCC, the underlying platform has to support
a C11 standard library.
Differential Revision: https://reviews.llvm.org/D108203
As a fly-by fix, also move it closer to where it is needed, and add a
comment explaining the existence of this weird function.
Differential Revision: https://reviews.llvm.org/D121231
operator-> is not a requirement for most iterators, so remove it. To
account for this change, the `common_iterator.operator->` test needs to
be refactored quite a bit -- improve test coverage while we're at it.
Differential Revision: https://reviews.llvm.org/D118400
Now that we've branched for the LLVM 14 release, our support window
moves to clang-13 and clang-14. Similarly, AppleClang 13 has been
released for some time now, so that should be the oldest compiler
we support, per our policy.
A possible follow-up would be to remove _LIBCPP_HAS_NO_CONCEPTS, since
I don't think we support any compiler that doesn't support concepts
anymore.
Differential Revision: https://reviews.llvm.org/D118831
This reverts commit 276ca873. That commit has quite a history at this
point. It was first landed in dbc647643577, which broke std::shared_ptr<T const>
and was reverted in 9138666f5. It was then re-applied in 276ca873, with
the std::shared_ptr issue fixed, but it caused widespread breakage at
Google (which suggests it would cause similar breakage in the wild too),
so now I'm reverting again.
Instead, I will add a escape hatch that vendors can turn on to enable
the extension and perform a phased transition over one or two releases
like we sometimes do when things become non-trivial.
These tests don't seem specific to the debug mode, so it makes sense to
run them even when the debug mode is disabled. When we run with the debug
mode enabled, we'll get the out-of-bounds checking that this test seems
to be concerned with.
Differential Revision: https://reviews.llvm.org/D121241
Based on review comments in D97705 applied some code cleanups in
<charconv>. The header now uses a more recent libc++ style.
Reviewed By: Quuxplusone, #libc, philnik
Differential Revision: https://reviews.llvm.org/D121223
LIBCXX_ENABLE_ASSERTIONS does not have any relationship to the `assert`
macro -- it only controls assertions that are internal to the library.
Playing around with `NDEBUG` only muddies the picture further than it
already is.
Also, remove a failing assertion in the benchmarks. That assertion had
never been exercised because we defined `NDEBUG` manually, and it was
failing since we introduced the ability to generate a benchmark vector
with the Quicksort adversary ordering (which is obviously not sorted).
This was split off of https://llvm.org/D121123.
Differential Revision: https://reviews.llvm.org/D121244
Those older versions used a different monetary decimal separator.
To avoid unnecessary churn to support that, just XFAIL the test
on those older versions. (Up until
df1e43c496, the whole test was XFAILed
on all versions of glibc.)
Differential Revision: https://reviews.llvm.org/D120979
On Windows, constants like F::alpha and F::print are bitmasks
consisting of multiple bits (e.g. F::alpha consisting of both the
bits F::upper and F::lower). In such a case, we can't check that
all the bits from all the expected constants are set. Instead,
check that (p[i] & mask) != 0 returns the expected value.
Differential Revision: https://reviews.llvm.org/D120802
This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.
This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.
This is a re-application of dbc647643577, which was reverted in 9138666f5
because it broke std::shared_ptr<T const>. Tests have now been added and
we've made sure that std::shared_ptr<T const> wouldn't be broken in this
version.
Differential Revision: https://reviews.llvm.org/D120996
As a fly-by fix, enable the complexity-changing assertions in __debug_less
only when the full debug mode is enabled, since debugging level 0 is usually
understood to only contain basic assertions that do not change the complexity
of algorithms.
Differential Revision: https://reviews.llvm.org/D121129
These are some checks that make sense in libc++ IMO. The checks after `#TODO: investigate these checks` are candidates, but they can't be enabled without some cleanup.
Reviewed By: ldionne, #libc
Spies: aheejin, libcxx-commits
Differential Revision: https://reviews.llvm.org/D120925
Saves one move in each case, which is basically nothing perf-wise;
this is more about simplifying the code.
Differential Revision: https://reviews.llvm.org/D121130
If LIBCXX_ENABLE_SHARED isn't explicitly set on the cmake command
line, isn't set in the cache, and the libcxxabi project is configured
before libcxx, then LIBCXX_ENABLE_SHARED isn't defined yet. Once
the libcxx cmake project has been parsed, LIBCXX_ENABLE_SHARED would
have been set to its default value of ON.
This makes sure that the symbols are properly dllexported in such
a configuration scenario.
Differential Revision: https://reviews.llvm.org/D120982
This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.
This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.
Differential Revision: https://reviews.llvm.org/D120996
Mark de Wever