Discovered in the comments on D118748: we would like this namespace
to exist anytime Ranges exists, regardless of whether concepts syntax
is supported. Also, we'd like to fully granularize the <ranges> header,
which means not putting any loose declarations at the top level.
Differential Revision: https://reviews.llvm.org/D118809
Remove the vector base class as suggested by @ldionne
Reviewed By: ldionne, Quuxplusone, #libc
Spies: libcxx-commits, ldionne
Differential Revision: https://reviews.llvm.org/D117108
The renames the output_iterator to cpp17_output_iterator. These
iterators are still used in C++20 so it's not possible to change the
current type to the new C++20 requirements. This is done in a similar
fashion as the cpp17_input_iterator.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D117950
As per [time.duration.cons]/1, the constructor constraint should be on
const Rep2&. As it is now the code will fail to compile in certain
cases, for example (https://godbolt.org/z/c7fPrcTYM):
struct S{
operator int() const&& noexcept = delete;
operator int() const& noexcept;
};
const S &fun();
auto k = std::chrono::microseconds{fun()};
Differential Revision: https://reviews.llvm.org/D118902
Removing the base class of std::basic_string is not an ABI break, so we can remove any references to it from the header.
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D118733
Note that most changes to `strings` and `views.span` from the One Ranges
Proposal are no longer applicable:
- free `begin` and `end` functions taking `basic_string_view` and `span`
were removed by [P1870](http://wg21.link/p1870);
- `span::const_iterator` was removed by [LWG3320](https://cplusplus.github.io/LWG/lwg-defects.html#3320).
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D118687
This started breaking in the CI because we bumped the Clang version
to 15, which requires adjusting the markup in the test suite.
Differential Revision: https://reviews.llvm.org/D118838
Per Discord discussion, we're normalizing on a simple `!defined(_LIBCPP_HAS_NO_CONCEPTS)`
so that we can do a big search-and-replace for `!defined(_LIBCPP_HAS_NO_CONCEPTS)`
back into `_LIBCPP_STD_VER > 17` when we're ready to abandon support for concept-syntax-less
compilers.
Differential Revision: https://reviews.llvm.org/D118748
There is no reason for the parts of std::span that don't depend on ranges
to be disabled when ranges aren't provided. Also, to make sure the
"no-experimental-stuff" configuration is tested, add a CI job for it.
Differential Revision: https://reviews.llvm.org/D118740
There is no practical difference between `_VSTD` and `std` so we should just remove `_VSTD`. This is the first step.
Reviewed By: ldionne, #libc
Spies: jeroen.dobbelaere, wmaxey, EricWF, lebedev.ri, __simt__, dim, mgrang, sstefan1, wenlei, smeenai, libcxx-commits, #libc_vendors
Differential Revision: https://reviews.llvm.org/D117811
In D117811 @Quuxplusone pointed out the friend declarations don't need
to be qualified. Removing the qualification should avoid needing to add
a GCC work-around when changing _VSTD to std.
Reviewed By: Quuxplusone, philnik, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D118719
With this patch there should be no more namespaces without closing comment
Reviewed By: ldionne, Quuxplusone, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D118668
The old `__regex_word` aliased the mask for `xdigit`, causing stray
test failures.
The diff may look surprising, as if the previous faulty value had
been set specifically for Windows - but this is due to a restructuring
in 411c630bae. Prior to that, there
were OS specific settings for some OSes, and one fallback used for
the rest (which turns out to not work for Windows).
Differential Revision: https://reviews.llvm.org/D118188
In ancient Microsoft C runtimes, there might only have been
a nonstandard `_vsnprintf` instead of the standard `vsnprintf`, but
in modern versions (the only ones relevant for libc++), both
are available.
In MinGW configurations built with `__USE_MINGW_ANSI_STDIO=1` (as it
is built in CI), `vsnprintf` provides a more standards compliant
behaviour than what Microsoft's CRT provides, while `_vsnprintf` retains
the Microsoft C runtime specific quirks.
Differential Revision: https://reviews.llvm.org/D118187
As discovered in D117817, `std::ranges::input_range<Holder<Incomplete>*[10]>`
hard-errored before this patch. That's because `input_range` requires
`iter_rvalue_reference_t`, which requires `iter_move`, which was
not ADL-proofed.
Add ADL-proofing tests to all the range refinements.
`output_range` and `common_range` shouldn't be affected,
and all the others subsume `input_range` anyway, but we might as
well be thorough.
Differential Revision: https://reviews.llvm.org/D118213
This includes an experimental workaround for
LWG3664 "LWG3392 broke std::ranges::distance(a, a+3)",
but the workaround may be incomplete, I'm not sure.
This should be re-audited when LWG3664 is actually adopted,
to see if we need to change anything about our implementation.
See also https://github.com/microsoft/STL/pull/2500
Differential Revision: https://reviews.llvm.org/D117940
Each "Nothing To Do" issue only changed nits in the English wording,
not anything to do with the code.
Each "Complete" issue was completed already, as far as I can tell.
I tried to err on the side of caution: I didn't mark a few issues
whose P/Rs were very invasive and would take time to verify, and I
didn't mark a lot of issues involving features we haven't even started
yet.
Differential Revision: https://reviews.llvm.org/D117960
The macro that opts out of `std::ranges::` functionality is called
`_LIBCPP_HAS_NO_INCOMPLETE_RANGES`, and is unrelated to this macro
which is specifically about _compiler_ support for the _syntax_.
The only non-mechanical diff here is in `<__config>`.
Differential Revision: https://reviews.llvm.org/D118507
I had a look at the changes since the last release and updated the
release notes with interesting changes.
It seems this time the release notes were already rather up to date :-)
If there are more interesting changes, please let me know and I'll
update the patch. I'd like to commit these changes latest next weekend
so they land before branching the 14.0 release.
I've added most active libc++ contributors. If I forgot anybody please add them.
Reviewed By: Quuxplusone, ldionne, philnik, #libc
Differential Revision: https://reviews.llvm.org/D117948
Remove copy and copy assignment rather than have them as private declarations.
They are superfluous given the move and move assignment.
As a drive-by, also specialize `std::hash` without reopening `namespace std`.
Differential Revision: https://reviews.llvm.org/D118502
We previously had a few varied definitions of this floating around.
I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior.
My compromise solution is this:
- No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt.
- Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too.
- Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision.
In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work.
The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and LLVM use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
These were omitted in all Windows configurations, but it turns out
that they work just fine in MinGW mode.
This allows converting a couple cases of "XFAIL: LIBCXX-WINDOWS-FIXME"
into "XFAIL: msvc" as the bug is specific to MSVC mode (clang-cl).
Differential Revision: https://reviews.llvm.org/D118192
The tests for these are just copy-pasted from the tests for std::{strong,weak,partial}_order,
and then I added an extra clause in each (test_2()) to test the stuff that's not just the same
as std::*_order.
This also includes the fix for https://wg21.link/LWG3465 (which falls naturally out of the
"you must write it three times" style, but I've added test cases for it also).
There is an action item here to go back and give good diagnostics for SFINAE failures
in these CPOs. I've filed this as https://github.com/llvm/llvm-project/issues/53456 .
Differential Revision: https://reviews.llvm.org/D111514
On targets that have limited atomic support, e.g. ones that define
ATOMIC_*_LOCK_FREE to '1' ("sometimes lock free"), we would end up
referencing yet-undefined __libcpp_{,un}signed_lock_free.
This commit adds a guard to prevent these references for such
targets.
Differential Revision: https://reviews.llvm.org/D118391
This explains stuff that most contributors already know, but it's always
good to write down explicitly.
Differential Revision: https://reviews.llvm.org/D118278
This should fix the regressions detected in D117992.
This lands before D117992 to avoid breaking main.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D118056
This move is going to be needed in order to reuse `posix_readdir` in
another translation unit. This doesn't change any of the code except
for removing an unused function parameter that otherwise triggers a
warning inside our tests.
Differential Revision: https://reviews.llvm.org/D118254
In `ranges::advance(iter, n, bound)`, we'd incorrectly handle the case
where bound < iter and n is 0:
int a[10];
int *p = a+5;
int *bound = a+3;
std::ranges::advance(p, 0, bound);
assert(p - a == 5); // we'd return 3 before this patch
This was caused by an incorrect handling of 0 inside __magnitude_geq.
Differential Revision: https://reviews.llvm.org/D117240
We were missing a constraint in common_iterator's iterator_traits and
we were eagerly instantiating iter_value_t even when invalid.
Thanks to Casey Carter for finding this bug.
Differential Revision: https://reviews.llvm.org/D117449
Fixed in counted_iterator and transform_view::iterator.
The LWG issue also affected elements_view::iterator, but we haven't
implemented that one yet, and whoever does implement it will get
the fix for free if they just follow the working draft's wording.
Drive-by stop calling `.base()` on test iterators in the test,
and improve the transform_view::iterator/sentinel tests.
Differential Revision: https://reviews.llvm.org/D117329
Remove a bunch of LIBCPP_CXX03_LANG. This is the result of a
rabbithole to re-eliminate the workaround I introduced into
std::cref in D117953. It turns out that Clang's C++03 mode
(the only compiler we care about C++03 for) now supports all
the things we were originally eschewing via LIBCPP_CXX03_LANG;
we can fully support these reference_wrapper features in
C++03 mode, and un-XFAIL the relevant tests.
Drive-by constexprify a few more tests.
Differential Revision: https://reviews.llvm.org/D117974
The Windows and Glibc abbreviated form of Saturday in French locale
is "sam." with a trailing period included. Account for this in the
test reference.
Differential Revision: https://reviews.llvm.org/D118240
This allows getting rid of one case of LIBCXX-WINDOWS-FIXME. The fixme
comment was inaccurate; aligned allocation functions are provided these
days, but the test kept failing as it was using mismatched allocation
and free functions.
A similar issue was fixed earlier, in
6596778b46. That test was fixed by
overriding the aligned `operator new` too, and returning a dummy fixed
allocation instead. As this test is libcxx specific, it can use the
internal `std::__libcpp_aligned_free()` instead, to match libcxx's
internal aligned `operator new`.
Differential Revision: https://reviews.llvm.org/D118190
These tests were formatted with older clang-format settings, this
updates them to the current settings.
In order to implement P2216 a lot of changes to these tests are
required. This makes it easier to review those patches.
https://cplusplus.github.io/LWG/issue3422
Also add a static_assert to check the "Mandates:" on the
iterator-pair constructor. Oddly, the `InputIterator` parameter
itself is merely preconditioned, not constrained, to satisfy the
input iterator requirements.
Also drive-by rename `init` to `__init`.
Differential Revision: https://reviews.llvm.org/D117962
Remove `std::basic_string`'s base class in ABI version 2
Reviewed By: Quuxplusone, ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D116334
* Default-initialized `basic_string` iterators are not portably in the domain of `==`.
* Avoid comparing iterators from non-equal string_views which MSVCSTL considers not to be in the domain of equality.
* Don't test invalid range `[in, out + N)`.
Also silence some truncation warnings by testing with a non-narrowing conversion.
Differential Revision: https://reviews.llvm.org/D118049
Since basic_string::reserve(n) is instantiated in the shared library but also
available to the compiler for inlining, its definition should not depend on
things like the Standard mode in use. Indeed, that flag may not match between
how the shared library is compiled and how users are compiling their own code,
resulting in ODR violations.
However, note that we retain the behavior of basic_string::reserve() to
shrink the string for backwards compatibility reasons. While it would
technically be conforming to not shrink, we believe user expectation is
for it to shrink, and so existing code might have been written based on
that assumption. We prefer to not break such code, even though that makes
basic_string::reserve() and basic_string::reserve(0) not equivalent anymore.
Fixes llvm-project#53170
Differential Revision: https://reviews.llvm.org/D117332
This adjust the version macro and sets it as completed. All parts of the paper
have been implemented, except for the parts replaced by later papers and
LWG-issues.
Adjusted the synopsis to match the synopsis in the Standard. Not yet
implemented parts of P2216 and P2418 still use the P0645 wording.
Completes:
- P0645 Text Formatting
Depends on D115991
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D115999
This implements the handler according to P0645. P2418 changes the wording
in the Standard. That isn't implemented and requires changes in more
places. LWG3631 applies modifications to P2418, but is currently
unresolved.
Implements parts of:
* P0645 Text Formatting
Depends on D115989
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D115991
[format.formatter.spec]/5 lists the requirements for the default
formatter. The original implementation didn't implement this. This
implements the default formatter according to the Standard.
This adds additional test to validate the default formatter is disabled
and the required standard formatters are enabled.
While adding the tests it seems the formatters needed a constraint for the
character types they were valid for.
Implements parts of:
- P0645 Text Formatting
Depends on D115988
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D115989
This implements the last required formatter specialization.
Completes:
- LWG 3251 Are std::format alignment specifiers applied to string arguments?
- LWG 3340 Formatting functions should throw on argument/format string mismatch in §[format.functions]
- LWG 3540 §[format.arg] There should be no const in basic_format_arg(const T* p)
Implements parts of:
- P0645 Text Formatting
Depends on D114001
Reviewed By: ldionne, vitaut, #libc
Differential Revision: https://reviews.llvm.org/D115988
This properly implements the formatter for floating-point types.
Completes:
- P1652R1 Printf corner cases in std::format
- LWG 3250 std::format: # (alternate form) for NaN and inf
- LWG 3243 std::format and negative zeroes
Implements parts of:
- P0645 Text Formatting
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D114001
Since their nested reference types are defined in terms of `iter_reference_t<T>`, which examines `decltype(*declval<T>())`.
Differential Revision: https://reviews.llvm.org/D117371
A number of the filesystem tests create a directory that contains a bad
symlink. On AIX recursively setting permissions on said directory will
return a non-zero value because of the bad symlink, however the
following rm -r still completes successfully. Avoid the assertion on
AIX, and rely on the return value of the remove command to detect
problems.
Differential Revision: https://reviews.llvm.org/D112086
Implement LWG3549 by making `view_interface` not inherit from `view_base`. Types
are still views if they have a public and unambiguous derivation from
`view_interface`, so adjust the `enable_view` machinery as such to account for
that.
Differential Revision: https://reviews.llvm.org/D117714
This will detect if someone writes `inline auto cpo =` instead of
`inline constexpr auto cpo =`. I don't know how that'd be possible,
but it's easy to test, so let's test it.
This addresses the usage of `operator&` in `<unordered_set>`.
(Note there are still more headers with the same issue.)
Reviewed By: #libc, philnik, Quuxplusone
Differential Revision: https://reviews.llvm.org/D117917
As discussed in https://reviews.llvm.org/D117714, there is missing test coverage
for the behavior of `enable_view` when given a const or reference qualified
type. Add such tests showing the current behavior.
Differential Revision: https://reviews.llvm.org/D117918
This addresses the usage of `operator&` in `<unordered_map>`.
(Note there are still more headers with the same issue.)
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D117393
This addresses the usage of `operator&` in `<unordered_map>`.
(Note there are still more headers with the same issue.)
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D117393
We previously had a few varied definitions of this floating around. I made the one installed with LLVM handle all the cases, and then made the others use it.
This issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and llvm use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
It was not in P0355R7, nor has it ever been so in a working draft.
Drive-by:
* tests should test something: fix loop bounds so initial value is not >= final value
* calender type streaming tests are useless - let's remove them
* don't declare printf, especially if you don't intend to use it
Differential Revision: https://reviews.llvm.org/D117638
As prefigured in the comments on D115315.
This gives us one unified style for all niebloids,
and also simplifies the modulemap.
Differential Revision: https://reviews.llvm.org/D116570
Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this
awkward, since the rest of the condition code may also need GNUInstallDirs.
The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward.
Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D117639
... rather than using `__has_builtin` directly. This both (1) allows a compiler that doesn't speak `__has_builtin` to workaround with preprocessor magic, and (2) avoids diagnostics about things that look like function like macros after `#if` but are not.
This is better than libunwind and libcxxabi fishing it out of libcxx's
module directory.
It is done in prepartion for a better version of D117537 which deduplicates
CMake logic instead of just renaming to avoid a name clash.
Reviewed By: phosek, #libunwind, #libc_abi, Ericson2314
Differential Revision: https://reviews.llvm.org/D117617
The gdb_pretty_printer_test.sh fails if GDB was built against Python 2.7
since Python 2 expects iterators to have a next() method rather than
using __next__. To make the pretty printers work with both Python 2 and 3
we can simply set next to __next__ in the iterator classes.
Python 2.7 support was removed in f46f93b478,
so this partially reverts that commit. While Python 2.7 is EOL, it
appears there are still many GDB installations that are linked against
Python 2.7, so we may want to keep this tiny amount of compat code
around for a while longer.
Without this commit the tests fails with errors such as:
```
GDB printed:
u"std::tuple containingTypeError: iter() returned non-iterator of type '_Children'\n"
Value should match:
u'std::tuple containing = {[1] = 2, [2] = 3, [3] = 4}'
```
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D117470
... it's easier to suppress warnings internally, where we can detect the compiler.
* Rename `TEST_COMPILER_C1XX` to `TEST_COMPILER_MSVC`
* Rename all `TEST_WORKAROUND_C1XX_<meow>` to `TEST_WORKAROUND_MSVC_<meow>`
Differential Revision: https://reviews.llvm.org/D117422
Currently it is not checked that operator in_in_result<II1, II2>() SFINAEs away properly
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D117517
`T` is not a valid identifier for libc++ to use, use `_Tp` instead. Caught from D116957
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D117582
The function `std::fill` requires a ForwardIterator, but `std::fill_n`
only requires an OutputIterator. Adds a test to validate `std::fill_n`
works with an OutputIterator.
Noticed this while working on LWG3539
format_to must not copy models of output_iterator<const charT&>
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D117395
Instead of storing the wrapped iterator inside the stride_counting_iterator,
store its base so we can have e.g. a stride_counting_iterator of an
input_iterator (which was previously impossible because input_iterators
are not copyable). Also a few other simplifications in stride_counting_iterator.
As a fly-by fix, remove the member base() functions, which are super
confusing.
Differential Revision: https://reviews.llvm.org/D116613
This change is the basis for a further refactoring where I'm going to
split up the various implementations we have in __threading_support to
make that code easier to understand.
Note that I had to make __convert_to_timespec a template to break
circular dependencies. Concretely, we never seem to use it with anything
other than ::timespec, but I am wary of hardcoding that assumption as
part of this change, since I suspect there's a reason for going through
these hoops in the first place.
Differential Revision: https://reviews.llvm.org/D116944
When invoking Lit repeatedly, we perform all the configuration checks
over and over again, which takes a lot of time. This patch allows caching
the result of configuration checks persistently across Lit invocations to
speed this up.
In theory, this should still be functionally correct since the cache
key should contain everything that determines the output of the
configuration check. However, in cases where e.g. the compiler has
changed but is at the same path as previously, the Lit configuration
checks will be cached even though technically the cache should have
been invalidated.
Differential Revision: https://reviews.llvm.org/D117361
This essentially reverts e02ed1c255 and puts in a new fix, which makes `path::iterator`
a true C++20 `bidirectional_iterator`, but downgrades it to an `input_iterator` in C++17.
Fixes#37852.
Differential Revision: https://reviews.llvm.org/D116489
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
The code in libc++ already satisfy the requirements of LWG-3373. Since
the issue was written to specifically allow the types to be used in
structured bindings, tests have been added to validate the new
requirement.
Implements
LWG-3373 {to,from}_chars_result and format_to_n_result need the "we really mean what we say" wording
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D117337
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
Force semicolons or remove them in `experimental/simd`
Reviewed By: Quuxplusone, ldionne, Mordante, #libc
Spies: libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D117157
I believe all four of these failures are directly due to the pattern where
allocations in the dylib are unobserved by the client program. If AIX32 and AIX64
don't support that, we should just disable the ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS
macro on AIX, and then we don't need to XFAIL these tests.
This also means I won't need to XFAIL a dozen other tests in D89057,
which rely heavily on ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS and
also currently fail on AIX.
See https://buildkite.com/llvm-project/libcxx-ci/builds/7669
Differential Revision: https://reviews.llvm.org/D116866
The aim of this patch is to break up the larger patch (https://reviews.llvm.org/D111323) to be more upstream friendly. In particular, this patch adds the char encoding sensitive changes but does not use inline namespaces as before. The use of namespaces to build both versions of the library, and localization of error messages will follow in a subsequent patch.
Differential Revision: https://reviews.llvm.org/D114813
I didn't split the calendar bits more than this because there was little
benefit to doing it, and I know our calendar support is incomplete.
Whoever picks up the missing calendar bits can organize these headers
at their leisure.
Differential Revision: https://reviews.llvm.org/D116965
... from testing with MSVC's STL. Mostly truncation warnings and variables that are only used in `LIBCPP_ASSERT`.
Differential Revision: https://reviews.llvm.org/D116878
This makes all the tests consistent and improves code coverage. This also
uncovers a bug with negative indices in advance() (which also impacts
prev()) -- I'll fix that in a subsequent patch.
I chose to only count operations in the tests for ranges::advance because
doing so in prev() and next() too was reaching diminishing returns, and
didn't meaningfully improve our test coverage.
Also remove some bogus `std::forward`s. My impression is that these
forwards were actually harmless, because `ranges::begin(FWD(t))` is
always identical to `ranges::begin(t)` (except when it's ill-formed,
and that can't happen in this case). However, they're also superfluous
and don't reflect the wording in the standard, so let's eliminate them.
Differential Revision: https://reviews.llvm.org/D117043
On Apple platforms, arc4random is faster than /dev/urandom, and it is
the recommended user-space RNG according to Apple's own OS folks.
This commit adds an ABI switch to guard ABI-break-protections in
std::random_device, and starts using arc4random instead of /dev/urandom
to implement std::random_device on Apple platforms.
Note that previously, `std::random_device` would allow passing a custom
token to its constructor, and that token would be interpreted as the name
of a file to read entropy from. This was implementation-defined and
undocumented. After this change, Apple platforms will be using arc4random()
instead, and any custom token passed to the constructor will be ignored.
This behavioral change will also impact other platforms that use the
arc4random() implementation, such as OpenBSD. This should be fine since
that is effectively a relaxation of the constructor's requirements.
rdar://86638350
Differential Revision: https://reviews.llvm.org/D116045
This needs a proper solution in a follow-up. The issue is that the
Standard defines conversions between `in_out_result` classes with
different template types as just `return {in, out};`. Because the
expression uses list initialization, it will fail to compile if the
conversion happens to be narrowing -- which is probably unintended.
Surprisingly, this error wasn't caught by the CI.
Differential Revision: https://reviews.llvm.org/D117089
Move `iter_swap.pass.cpp` into a new subdirectory: `iterator.cust.swap`
for symmetry with the neighboring subdirectory `iterator.cust.move`.
Differential Revision: https://reviews.llvm.org/D116992
Introduce `__fits_in_sso()` to put the constexpr tests into a central place.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D116487
There are a lot of
```
#if _LIBCPP_DEBUG_LEVEL == 2
__get_db()->__insert_c(this);
#endif
```
This patch introduces `__debug_db_insert_c()` to put the `#if` in one central place.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D116947
In D116873 I did this for libunwind prior to defining a new install path
variable. But I think the change is good on its own, and libc++{,abi}
could also use it.
libc++ needed the base header var defined above the conditional part to
use it for the prefi+ed headers in the non-target-specific case. For
consistency, I therefore put the unconditional ones above for all 3
libs, which is why I touched the libunwind code (seeing that it had the
core change already)
Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D116988
... even when `!defined(_LIBCPP_VERSION)`. (Note that the previous definition for this case - `((void)0);` - is ill-formed at namespace scope.) Ditto for `LIBCPP_ASSERT`, `LIBCPP_ASSERT_NOEXCEPT`, `LIBCPP_ASSERT_NOT_NOEXCEPT`, and `LIBCPP_ONLY`.
Differential Revision: https://reviews.llvm.org/D116880
That will make it easier to change the behavior of the arc4random()
based implementation. Note that in particular, the eval.pass.cpp test
used to work with non "/dev/random" based implementations because we'd
throw an exception upon constructing the random_device. This patch makes
the intent of the test clearer.
The NFC part of D116809. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.
Differential Revision: https://reviews.llvm.org/D116809
Use the zx_clock_get_monotonic system call directly rather than
going through the POSIX clock_gettime function. The libc function
is a trivial wrapper around the system call, and is not a standard C
function. Avoiding it reduces the Fuchsia libc ABI surface that
libc++ depends on.
Reviewed By: phosek, ldionne, #libc
Differential Revision: https://reviews.llvm.org/D116606
Before this patch, the user needed to specialize both of
`is_placeholder<MyType>` and `is_placeholder<const MyType>`.
After this patch, only the former is needed (although the
latter is harmless if provided).
The new tests don't actually fail unless return type deduction
is used, which is a C++14 feature. Specializing `is_placeholder`
is still allowed in C++11, though.
Fixes#51095.
Differential Revision: https://reviews.llvm.org/D116388
The documentation CI job is very cheap, so we can afford to keep it
around even with reduced capacity. This commit fixes the documentation
(which had an invalid reference in it) and re-enables that CI step.
Differential Revision: https://reviews.llvm.org/D116897
Casey Carter says, "We run std/thread/thread.mutex/thread.lock.algorithm/lock.pass.cpp
on every CI and it works fine with MSVC STL. I'm guessing this annotation predates
Billy's rewrite of std::lock in 2017-ish."
Differential Revision: https://reviews.llvm.org/D116712
The reason for those nested namespaces is explained in D115315:
> AIUI, this keeps the CPO's own type from ADL'ing into the `std::ranges`
> namespace; e.g. `foobar(std::ranges::uninitialized_default_construct)`
> should not consider `std::ranges::foobar` a candidate, even if
> `std::ranges::foobar` is not a CPO itself. Also, of course, consistency
> (Chesterton's Fence, the economist's hundred-dollar bill): if it were
> safe to omit the namespace, we'd certainly want to do it everywhere,
> not just here.
This makes these three niebloids more consistent with the other Ranges
niebloids we've already implemented, such as the `ranges::begin` group
and the `ranges::uninitialized_default_construct` group.
FWIW, we still have three different indentation-and-comment styles
among these three groups.
Differential Revision: https://reviews.llvm.org/D116569
When building libcxx, libcxxabi, and libunwind the build environment may
specify any number of sanitizers. For some build feature tests these
sanitizers must be disabled to prevent spurious linking errors. With
-fsanitize= this is straight forward with -fno-sanitize=all. With
-fsanitize-coverage= there is no -fno-sanitize-coverage=all, but there
is the equivalent undocumented but tested -fsanitize-coverage=0.
The current build rules fail to disable 'trace-pc-guard'. By disabling
all sanitize-coverage flags, including 'trace-pc-guard', possible
spurious linker errors are prevented. In particular, this allows libcxx,
libcxxabi, and libunwind to be built with HonggFuzz.
CMAKE_REQUIRED_FLAGS is extra compile flags when running CMake build
configuration steps (like check_cxx_compiler_flag). It does not affect
the compile flags for the actual build of the project (unless of course
these flags change whether or not a given source compiles and links or
not). So libcxx, libcxxabi, and libunwind will still be built with any
specified sanitize-coverage as before. The build configuration steps
(which are mostly checking to see if certain compiler flags are
available) will not try to compile and link "int main() { return 0;}"
(or other specified source) with sanitize-coverage (which can fail to
link at this stage in building, since the final compile flags required
are yet to be determined).
The change to LIBFUZZER_CFLAGS was done to keep it consistent with the
obvious intention of disabling all sanitize-coverage. This appears to
be intentional, preventing the fuzzer driver itself from showing up in
any coverage calculations.
Reviewed By: #libunwind, #libc, #libc_abi, ldionne, phosek
Differential Revision: https://reviews.llvm.org/D116050
In the test files, replace the old-style tests with a simple static_assert,
matching the current style as depicted in e.g.
`ranges_uninitialized_default_construct.pass.cpp`.
Preserve `is_function_like` (but renamed to `is_niebloid`) at
ldionne's request. The removal of this test helper will happen
in D116570 if at all.
Differential Revision: https://reviews.llvm.org/D116384
This should have been done in 6a6a80e88e, but buildkite was down so I
hadn't noticed. This brings this test file into line with several others
in this directory.
z/OS doesn't support fopen64() functions. Modify the preprocessor directive for z/OS to use fopen() instead.
Reviewed By: #libc, abhina.sreeskantharajan, muiez, ldionne
Differential Revision: https://reviews.llvm.org/D111226
Although we moved to Github Issues. The bug report message refers to
Bugzilla still. This patch tries to update these URLs.
Reviewed By: MaskRay, Quuxplusone, jhenderson, libunwind, libc++
Differential Revision: https://reviews.llvm.org/D116351
This reverts commit 640beb38e7.
That commit caused performance degradtion in Quicksilver test QS:sGPU and a functional test failure in (rocPRIM rocprim.device_segmented_radix_sort).
Reverting until we have a better solution to s_cselect_b64 codegen cleanup
Change-Id: Ibf8e397df94001f248fba609f072088a46abae08
Reviewed By: kzhuravl
Differential Revision: https://reviews.llvm.org/D115960
Change-Id: Id169459ce4dfffa857d5645a0af50b0063ce1105
The fix in D116381 makes an existing exception message wrong. This
improves the message and fixes the associated unit tests.
Note other message can be also be improved, but that will be done later.
Changing these messages may cause merge conflicts with other patches
that are under review or WIP.
Depends on D116381
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D116495
@CaseyCarter reported that the tests for the std-format-spec rejects leading
zeroes for precision, which the Standard does not require. The Standard allows
them. Only for precision, not for the width or an arg-id.
Fixes the precision parser and adds some test for the arg-id since they
were missing.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D116381
Remove duplicate header includes from `<algorithm>` and reorder the includes
Reviewed By: Quuxplusone, ldionne, Mordante, #libc, jloser
Spies: jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D116507
`__cpp_lib_type_identity` was implemented way back in cf49ccd0 (Clang 8),
probably before the feature-test macro had been settled on.
`__cpp_lib_string_resize_and_overwrite` will be added by D113013 so I didn't add it here.
Fixes#46605.
Differential Revision: https://reviews.llvm.org/D116433
For example, `std::ranges::range<Holder<Incomplete>*>` should be
well-formed false, not a hard error at compile time.
Differential Revision: https://reviews.llvm.org/D116239
The big change here is that they now work as intended for rvalues,
e.g. `ranges::cbegin(std::string_view("hello"))`.
Also, add tests verifying their return types.
Differential Revision: https://reviews.llvm.org/D116199
If `__first == __middle`, then `partial_sort` is a no-op; don't
bother to iterate all the way from `__middle` to `__end`.
Fixes#49431.
Differential Revision: https://reviews.llvm.org/D116296
AFAICT, Cpp17InputIterators are not required to be default constructible,
since that requirement is added in Cpp17ForwardIterator. Hence, our
archetype for Cpp17InputIterator should not be default constructible.
Removing that constructor has a ripple effect on a couple of tests that
were making incorrect assumptions. Notably:
- Some tests were using cpp17_input_iterator as a sentinel for itself.
That is not valid, because a cpp17_input_iterator is not semiregular
anymore after the change (and hence it doesn't satisfy sentinel_for).
- Some tests were using a stride-counted cpp17_input_iterator as the
sentinel for a range. This doesn't work anymore because of the problem
above, so these tests were changed not to check stride counts for
input iterators.
- Some tests were default constructing cpp17_input_iterator when a simple
alternative was available -- those have been changed to use that alternative.
Differential Revision: https://reviews.llvm.org/D115806
Some headers which require the version header depend on other headers to
provide it. Include the version header in all top-level headers to make
sure a header cleanup can't remove the version header.
Note this doesn't add the version header to the c headers.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D116172
Use the zx_cprng_draw system call directly rather than going
through the libc getentropy function. The libc function is a
trivial wrapper around the system call, and is not a standard C
function. Avoiding it reduces the Fuchsia libc ABI surface that
libc++ depends on.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D116498
In D116472 we created conditionally defined variables for the tools to
unbreak the legacy build where they are in `llvm/tools`.
The runtimes are not tools, so that flexibility doesn't matter. Still,
it might be nice to define (unconditionally) and use the variable for
the runtimes simply to make the code a bit clearer and document what is
going on.
Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path.
Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D116477
There is an ongoing CI outage with our Linux nodes, so I temporarily
set up a couple of nodes. These nodes will be much slower than the
usual ones and there's only a few of them, so I am temporarily disabling
most of our CI to keep things working.
Line 1140 is a duplicate of line 1119; it tests the two-argument version
of std::hypot, whereas all the lines in this section are supposed to be
testing the C++17 three-argument version. Remove the erroneous duplicated line.
Split out of D116295.
Some individual test files verify the CPO under test satisfies
`semiregular` concept. This is redundant since it is already part of the test
in verifying whether the entity is indeed a CPO in
`libcxx/test/std/library/description/conventions/customization.point.object/cpo.compile.pass.cpp`.
Differential Revision: https://reviews.llvm.org/D116173
We didn't support noop_coroutine for GCC in previous conforming patch.
So that GCC couldn't use noop_coroutine() defined in <coroutine>. And
after this patch, GCC should be able to compile the whole <coroutine>
header.
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D116144
It was missing the cast to `bool` in `bool(__t.empty())`.
It was wrongly using `std::forward` in some places.
Differential Revision: https://reviews.llvm.org/D115312
During the review of D115991 @vitaut pointed out the enum shouldn't
depend on whether or not _LIBCPP_HAS_NO_INT128 is defined. The current
implementation lets the enum's ABI depend on this configuration option
without a good cause.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D116120
These headers have stabilized; we don't expect anyone to be
blindly clang-formatting them anymore.
Leave the comments in `__format/*.h` for Mark to remove at his leisure.
Clang is gaining `auto(x)` support in D113393; sadly there
seems to be no feature-test macro for it. Zhihao is opening
a core issue for that macro.
Use `_LIBCPP_AUTO_CAST` where C++20 specifies we should use `auto(x)`;
stop using `__decay_copy(x)` in those places.
In fact, remove `__decay_copy` entirely. As of C++20, it's purely
a paper specification tool signifying "Return just `x`, but it was
perfect-forwarded, so we understand you're going to have to call
its move-constructor sometimes." I believe there's no reason we'd
ever need to do its operation explicitly in code.
This heisenbugs away a test failure on MinGW; see D112214.
Differential Revision: https://reviews.llvm.org/D115686
As discussed with ldionne. The problem with this static_assert
is that it makes ranges::begin a pitfall for anyone ever to use
inside a constraint or decltype. Many Ranges things, such as ranges::size,
are specified as "Does X if X is well-formed, or else Y if Y is well-formed,
or else `ranges::end(t) - ranges::begin(t)` if that is well-formed, or else..."
And if there's a static_assert hidden inside `ranges::begin(t)`, then you get
a hard error as soon as you ask the question -- even if the answer would have
been "no, that's not well-formed"!
Constraining on `requires { t + 0; }` or `requires { t + N; }` is verboten
because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103700 . For ranges::begin,
we can just decay to a pointer even in the incomplete-type case. For ranges::end,
we can safely constrain on `sizeof(*t)`. Yes, this means that an array of incomplete
type has a `ranges::begin` but no `ranges::end`... just like an unbounded array of
complete type. This is a valid manifestation of IFNDR.
All of the new libcxx/test/std/ cases are mandatory behavior, as far as I'm aware.
Tests for the IFNDR cases in ranges::begin and ranges::end remain in `libcxx/test/libcxx/`.
The similar tests for ranges::empty and ranges::data were simply wrong, AFAIK.
Differential Revision: https://reviews.llvm.org/D115838
The paths to the compiler and to the python executable may need to
be quoted (if they're installed into e.g. C:\Program Files).
All testing commands that are executed expect a gcc compatible command
line interface, while clang-cl uses different command line options.
In the original testing config, if the chosen compiler was clang-cl, it
was replaced with clang++ by looking for such an executable in the path.
For the new from-scratch test configs, I instead chose to add
"--driver-mode=g++" to flags - invoking "clang-cl --driver-mode=g++"
has the same effect as invoking "clang++", without needing to run any
heuristics for picking a different compiler executable.
Differential Revision: https://reviews.llvm.org/D111202
While there's little value in polishing the old config system,
I ran into this function and was confused for a while, while grepping
around and trying to wrap my head around things.
Differential Revision: https://reviews.llvm.org/D116131
The test is currently marked XFAIL for mingw environments, but latest
mingw-w64 got support for timespec_get:
e62a0a987c
The CI environment will probably be upgraded to a state where this
test is passing only after 14.x is branched in the llvm-project monorepo.
If we'd just go from having an XFAIL to no marking at all (when CI is
passing), we'd have to update both main and 14.x branches in sync
exactly when the CI runners are updated to a newer version.
Instead, mark the test as temporarily unsupported (so it doesn't
cause failed builds when the CI environment is updated); after the
CI environments are upgraded to such a state, we can remove the
UNSUPPORTED marking to start requiring it to pass on the main branch,
without needing to synchronize that change to anything else.
Differential Revision: https://reviews.llvm.org/D116132
Eliminate a bogus operator== overload.
Also, check more intermediate steps in the logic we're checking here.
Some of this simplification is possible only now that we've implemented
more of <ranges>.
Differential Revision: https://reviews.llvm.org/D116002
If %{exec} sets "--env PATH=single-dir", the directory containing
bash and related shell utils is omitted from the path, which means
that most shell scripts would fail.
(Setting PATH is needed for DLL builds on Windows; PATH fills the same
role as e.g. LD_LIBRARY_PATH on Linux.)
This condition is missed in the current test, because the executor
run.py first resolves the executable to run using the original path,
then invokes that executable with an environment with a restricted
path. Thus the executor is able to run bash, but that bash is then
unable to run further shell commands (other than bash builtins).
Extend the test from "bash --version" to "bash -c 'bash --version'".
This correctly identifies the executor-has-no-bash condition in the
current Windows CI configs, allowing removing 6 cases of
LIBCXX-WINDOWS-FIXME.
Another longterm fix would be to extend run.py with an option like
"--env-prepend PATH=dir", to allow keeping the current path while
adding a directory to it.
Differential Revision: https://reviews.llvm.org/D116117
This is similar to the existing setting LIBCXX_ABI_DEFINES, with
the difference that this also allows setting other defines than
ones that start with "_LIBCPP_ABI_", and allows setting defines
to a specific value.
This allows avoiding using LIBCXX_TEST_COMPILER_FLAGS in two
CI configurations.
Differential Revision: https://reviews.llvm.org/D116109
This allows cross-testing (by setting LIBCXX_EXECUTOR to point
to ssh.py) without making an entirely new test config file.
Implicitly, this also fixes quoting of the python executable name
(which is quoted in test/CMakeLists.txt).
Differential Revision: https://reviews.llvm.org/D115398
We can't just memoize _supportsVerify in place in format.py, as it
previously was executed in each of the individual processes.
Instead use hasCompileFlag() and add a feature flag for it instead,
which can be used both by tests (that already have such a flag,
locally for one set of tests) and for the testing framework itself.
By using hasCompileFlag(), this also implicitly fixes two other issues:
Previously, _supportsVerify called subprocess.call() directly, which can
interpret command line quoting differently than lit.TestRunner.
(In particular, TestRunner handles arguments quoted by a single quote,
while launching Windows processes with subprocess.call() only supports
double quotes. This allows using shlex.quote(), which uses single quotes,
everywhere - as all commands now go through TestRunner. This should make
41d7909368 redundant.)
Secondly, the old _supportsVerify method didn't include %{flags) or
%{compile_flags}.
Differential Revision: https://reviews.llvm.org/D116010
Add test for various customization point object properties as defined by
the Standard. Test various CPOs from `<ranges>`, `<iterator>`,
`<concepts>`, etc.
The test is mostly from https://reviews.llvm.org/D107036 and split up
into this.
Differential Revision: https://reviews.llvm.org/D115588
Allow `__move_constexpr` to work with unrelated pointers and `_LIBCPP_ASSERT` that `__copy_constexpr`, `__move_constexpr` and `__assign_constexpr` are only run during constant evaluation
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D115986
When P0883R2 was initially implemented in D103769 #pragma clang deprecated didn't exist yet.
We also forgot to cleanup usages in libc++ itself.
This takes care of both.
Differential Revision: https://reviews.llvm.org/D115995
__transaction is a helper class that allows rolling back code in case an
exception is thrown. The main goal is to reduce the clutter when code
needs to be guarded with `#if _LIBCPP_NO_EXCEPTIONS`.
Differential Revision: https://reviews.llvm.org/D115730
Also:
- refactor out `__voidify`;
- use the `destroy` algorithm internally;
- refactor out helper classes used in tests for `uninitialized_*`
algorithms.
Differential Revision: https://reviews.llvm.org/D115626
When run in a git bash terminal, sys.stderr isn't flushed implicitly
after printing each line. Manually flush it after each printout,
to avoid getting broken/misordered output.
A similar fix had been done in the old libcxx test config, committed
as part of 7e3ee09ad2 / D28725; this
generalizes the fix, making it available in the new libcxx test
configs too, and for any other test that uses lit_config.note().
Differential Revision: https://reviews.llvm.org/D115761
The inline keyword is required on those functions because they are defined
in the headers, so we need them to be inline to avoid ODR violations.
While we're at it, slap _LIBCPP_HIDE_FROM_ABI on them because they are
implementation details and we don't want them to be part of our ABI under
any circumstances.
Differential Revision: https://reviews.llvm.org/D115906
There is no need to check the counters on `Counted` after destroying
elements in the range because these tests are not testing `destroy`.
Differential Revision: https://reviews.llvm.org/D115839
Remove `s.base()`; every test that wants to get the base of a "test sentinel"
should use the ADL `base(s)` from now on.
Differential Revision: https://reviews.llvm.org/D115766
GCC currently does not allow `__builtin_strlen()` during constant evaluation. This PR adds a workaround in `std::char_traits<char>::length()`
Reviewed By: Quuxplusone, ldionne, #libc, Mordante
Spies: Mordante, libcxx-commits
Differential Revision: https://reviews.llvm.org/D115795
However, there's a problem on both GCC and Clang: they can't mangle
`__is_same(T,U)` if it appears anywhere that affects mangling. That's
a hard error. And it turns out that GCC puts dependent return types
into the mangling more aggressively than Clang, so for GCC's benefit
we need to avoid using raw `_IsSame` in the return type of
`swap(tuple&, tuple&)`. Therefore, make `__all` into a named type
instead of an alias.
If we ever need to support a compiler without the __is_same builtin,
we can make this an alias template for `is_same<T,U>::type`.
Differential Revision: https://reviews.llvm.org/D115100
Use `_LIBCPP_DEBUG_ASSERT` instead of `_LIBCPP_ASSERT` and guarding it with `LIBCPP_DEBUG_LEVEL == 2`
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D115765
Defined in [`specialized.algorithms`](wg21.link/specialized.algorithms).
Also:
- refactor the existing non-range implementation so that most of it
can be shared between the range-based and non-range-based algorithms;
- remove an existing test for the non-range version of
`uninitialized_default_construct{,_n}` that likely triggered undefined
behavior (it read the values of built-ins after default-initializing
them, essentially reading uninitialized memory).
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D115315
A few tests in the test suite require support for Bash. For example,
tests that run a program and send data through stdin to it require some
way of piping the data in, and we use a Bash script for that.
However, some executors (e.g. an embedded systems simulator) do not
support Bash, so these tests will fail. This commit adds a Lit feature
that tries to detect whether Bash is available through conventional
means, and disables the tests that require it otherwise.
Differential Revision: https://reviews.llvm.org/D114612
The library is always build using C++20 so these guards are not needed.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D115644
As explained in https://stackoverflow.com/a/70339311/627587, the fact
that shrink_to_fit wasn't defined as inline lead to issues when explicitly
instantiating basic_string. While explicit instantiations are always
somewhat brittle, this one was clearly a bug on our end.
Differential Revision: https://reviews.llvm.org/D115656
Arthur O'Dwyer