The changes from the One Ranges Proposal amount to adding:
- a constructor that takes a `default_sentinel_t` and is equivalent to
the default constructor;
- an `operator==` that compares the iterator to `default_sentinel_t`.
The original proposal defined two overloads for `operator==` (different
argument order) as well as `operator!=`. This has been removed by
[P1614](https://wg21.link/p1614).
Differential Revision: https://reviews.llvm.org/D119620
I'm trying to get libc++ to the point of being able to run clang-tidy. This is a PR to see if clang-tidy is happy with all the CI configs.
Reviewed By: Quuxplusone, ldionne, #libc
Spies: mgorny, aheejin, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D117174
We shouldn't be calling `distance` via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
this ADL ability of `distance` in particular.
Differential Revision: https://reviews.llvm.org/D119685
This change will make it possible to track exported symbols in more
configurations, notably the Apple system one, where we disable incomplete
features and the debug mode. Also, as a fly-by fix, shorten the name for
whether new is in libc++ or not.
Differential Revision: https://reviews.llvm.org/D119764
Also, fix the actual code so that the test would pass if we fixed the
issue that the method is instantiated in the dylib, and hence the debug
assertion will never fire except if the debug mode is enabled when the
dylib is being compiled.
Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/include/.
I've left `#include "include/x.h"` and `#include "../y.h"` alone
because I'm less sure that they're interchangeable, and they aren't
inconsistent with libcxx/include/ because libcxx/include/ never
does that kind of thing.
Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`,
even though it's technically unnecessary in a standalone .cpp file,
just so we have consistently one way to do it.
Differential Revision: https://reviews.llvm.org/D119561
This should work now that we are using a matching libunwind.dylib when
we run the tests in back-deployment scenarios. The only restriction we
have now is to run on macOS x86_64, since that's what the old dylibs
were compiled for. This should allow us to move to newer AppleClangs
in the CI.
As a fly-by, fix missing availability annotations on optional's
monadic operations.
Differential Revision: https://reviews.llvm.org/D119840
As suggested in D117966.
These conditional noexcepts are *permitted* by the Standard (as long
as there were no mistakes in them, I guess); but not *mandated*.
The Standard doesn't put any noexcept-specifications on these member functions.
The same logic would apply to `transform_view::iterator::operator*`
and `transform_view::iterator::operator[]`, but the Standard mandates
conditional noexcept on `iter_move(transform_view::iterator)`, and
I think it doesn't make much sense to say "moving from this iterator
is conditionally noexcept but not-moving from it is noexcept(false),"
so I'm leaving transform_view alone for now.
Differential Revision: https://reviews.llvm.org/D119374
In src/, most files can use `constinit` directly because they're always
compiled with C++20. But some files, like "libcxxabi/src/fallback_malloc.cpp",
can't, because they're `#include`d directly from test cases in libcxxabi/test/
and therefore must (currently) compile as C++03. We might consider refactoring
those offending tests, or at least marking them `UNSUPPORTED: c++03`.
Differential Revision: https://reviews.llvm.org/D119264
The logic here is that we are disabling *only* things in `std::ranges::`.
Everything in `std::` is permitted, including `default_sentinel`, `contiguous_iterator`,
`common_iterator`, `projected`, `swappable`, and so on. Then, we include
anything from `std::ranges::` that is required in order to make those things
work: `ranges::swap`, `ranges::swap_ranges`, `input_range`, `ranges::begin`,
`ranges::iter_move`, and so on. But then that's all. Everything else (including
notably all of the "views" and the `std::views` namespace itself) is still
locked up behind `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`.
Differential Revision: https://reviews.llvm.org/D118736
The test would trigger -Wtautological-compare. I think that the little
we gain from comparing addresses isn't worth the added complexity to
work around the warning.
Summary:
The pragma priority guarded for AIX in locale.cpp is no longer useful and is ignored by the current AIX build compilers. This patch removes it from the source.
Reviewed by: ldionne, hubert.reinterpretcast, libc++
Differential Revision: https://reviews.llvm.org/D119765
This makes the GCC output even cleaner!
Reviewed By: ldionne, #libc
Spies: mstorsjo, Quuxplusone, Mordante, libcxx-commits
Differential Revision: https://reviews.llvm.org/D119295
We added one for libc++ recently, and this patch adds one for libc++abi.
Also, as a fly-by fix, include older libunwind dylibs in the testing of
libc++ and libc++abi, which fixes some issues related to running
back-deployment tests on newer systems.
Differential Revision: https://reviews.llvm.org/D119466
This test feeds in the expected utf8 form of weekdays in various
languages, trying to match what libc++ has gathered internally
from `strftime()`. On glibc, the ru_RU.UTF-8 representation of the
tested weekday is spelled with upper case, while the existing
test reference is lower case.
Differential Revision: https://reviews.llvm.org/D118237
Also opt in to testing the hexadecimal float formatting for glibc; glibc
does matches the current test references there.
Differential Revision: https://reviews.llvm.org/D118238
This fixes warnings about implicitly declared `_umul128` and
`__shiftright128` when building for x86_64 with clang-cl.
Use `_MSC_VER` instead of `_LIBCPP_COMPILER_MSVC` for enabling MSVC
specific code; `_MSC_VER` is defined both in clang-cl and MSVC,
while `_LIBCPP_COMPILER_MSVC` only is defined if building with the
actual MSVC compiler.
Include `ryu.h` at the head of `d2s_intrinsics.h`, as it uses
the `_LIBCPP_64_BIT` define, which is defined in `ryu.h`.
Now the Ryu files build without warnings with clang-cl for i386,
x86_64, arm and aarch64.
Differential Revision: https://reviews.llvm.org/D119647
`<filesystem>` header has been around for a while now, so we can safely remove
`<experimental/filesystem>` header. `_LIBCPP_DEPRECATED_EXPERIMENTAL_FILESYSTEM`
suggests we were going to remove `<experimental/filesystem>` in llvm 11 release,
but we never did. So, remove the experimental header now, its associated tests,
and the `_LIBCPP_DEPRECATED_EXPERIMENTAL_FILESYSTEM` macro.
Differential Revision: https://reviews.llvm.org/D119603
Despite the comment saying `[[no_unique_address]]` on the `__base_` data member
makes clang crash, this does not seem to be true on CI. So, mark `__base_` with
`_LIBCPP_NO_UNIQUE_ADDRESS`.
Differential Revision: https://reviews.llvm.org/D119208
- add some test cases for `cbegin`/`cend`;
- make class definitions generally follow the order in which they are
used;
- add a missing include.
Reviewed By: philnik
Differential Revision: https://reviews.llvm.org/D119214
This reverts commit 2722ac65. As explained in D115906, this was actually
unnecessary and it broke the external threading configuration.
Differential Revision: https://reviews.llvm.org/D119484
This works around a known issue in ASan. ASan doesn't instrument weak
symbols. Because instrumentation increases object size, the binary can
end up with two versions of the same object, one instrumented and one
not instrumented, with different sizes, which ASan will report as an ODR
violation. In libc++, this affects typeinfo for `std::bad_function_call`
which is emitted as a weak symbol in the test executable and as a strong
symbol in the shared library.
The main open issue for ASan appears to be
https://github.com/google/sanitizers/issues/1017.
Differential Revision: https://reviews.llvm.org/D119410
`ranges_swap_ranges.h` includes `<type_traits>` but does not use anything from
it. So, remove the include.
Differential Revision: https://reviews.llvm.org/D119491
This avoids using an libc++ internal macro in our tests. This version
doesn't depend on the internal macro but redefines it.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D119460
`{back,front}_insert_iterator` and `ostream{,buf}_iterator` effectively
fully implement the One Ranges Proposal already, so mark them as done:
- the change to `difference_type` was made by D103273;
- default constructors and the associated default member initializers
were removed by wg21.link/P2325 (implemented by D102468).
Also fix a stale template signature in the `<iterator>` synopsis.
We are moving away from building the runtimes with LLVM_ENABLE_PROJECTS,
however the documentation was largely outdated. This commit updates all
the documentation I could find to use LLVM_ENABLE_RUNTIMES instead of
LLVM_ENABLE_PROJECTS for building runtimes.
Note that in the near future, libcxx, libcxxabi and libunwind will stop
supporting being built with LLVM_ENABLE_PROJECTS altogether. I don't know
what the plans are for other runtimes like libc, openmp and compiler-rt,
so I didn't make any changes to the documentation that would imply
something for those projects.
Once this lands, I will also cherry-pick this on the release/14.x branch
to make sure that LLVM's documentation is up-to-date and reflects what
we intend to support in the future.
Differential Revision: https://reviews.llvm.org/D119351
In libc++, checking specific `_LIBCPP_DEBUG_LEVEL` levels is used everywhere except in `comp_ref_type.h`. `_LIBCPP_DEBUG` is meant as a user-facing option, and internally libc++ should be checking the value of `_LIBCPP_DEBUG_LEVEL`.
The definition of `std::__debug_less` doesn't need to be hidden behind the macro, we can unconditionally expose it. It will be unused by `__comp_ref_type` unless debug mode is enabled.
This was suggested in D118940.
Reviewed By: #libc, philnik, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D118950
b07b5bd727 adds a use of `__comp_ref_type.h` to `std::min`. When libc++ is built with `-D_LIBCPP_DEBUG=0`, this enables `std::__debug_less`, which is only marked constexpr after c++17.
`std::min` itself is marked as being `constexpr` as of c++14, so by extension, `std::__debug_less` should also be marked `constexpr` for the same versions so that `std::min` can use it. This change lowers the guard from `> 17` to `> 11`.
Reproducer in godbolt: https://godbolt.org/z/ans3TGsj8
```
constexpr int x() { return std::min<int>({1, 2, 3, 4}); }
static_assert(x() == 1);
```
Reviewed By: #libc, philnik, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D118940
Glibc adds a +-sign for NaN-values when showpos fmtflags are set.
[tab:ios.fmtflags]
showpos generates a + sign in non-negative generated numeric output
Since NaNs aren't negative this behaviour seems correct. Enable the test
for glibc and add ifdefs to make sure the existing tests still pass.
This was noticed while working on D118971.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D119260
Standalone build have been deprecated for some time now, so this
commit removes support for those builds entirely from libc++, libc++abi
and libunwind.
This, along with the removal of other legacy ways to build, will allow
for major build system simplifications.
Differential Revision: https://reviews.llvm.org/D119255
Remove mentions of `experimental::function`, its operators, etc. They are no
longer in `experimental/functional`.
Differential Revision: https://reviews.llvm.org/D119204
Previously, _LIBCPP_ABI_UNSTABLE would be used interchangeably with
_LIBCPP_ABI_VERSION >= 2. This was confusing and creating unnecessary
complexity.
This patch removes _LIBCPP_ABI_UNSTABLE -- instead, the LIBCXX_ABI_UNSTABLE
CMake option will result in the LIBCXX_ABI_VERSION being set to '2', the
current unstable ABI. As a result, in the code, we only have _LIBCPP_ABI_VERSION
to check in order to query the current ABI version.
As a fly-by, this also defines the ABI namespace during CMake configuration
to reduce complexity in __config. I believe it was previously done this
way because we used to try to use __config_site as seldom as possible.
Now that we always ship a __config_site, it doesn't really matter and
I think being explicit about how the library is configured in the __config_site
is actually a feature.
Differential Revision: https://reviews.llvm.org/D119173
This change is a preparation for adapting the tests for
P2216 std::format improvements
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D118717
This testing configuration links tests against one libc++ shared library,
but runs them against another libc++ shared library. This makes sure that
we can build applications against the libc++ provided in a recent SDK and
back-deploy them to platforms containing older libc++ dylibs.
It also switches the Apple CI script to using that new configuration
instead of the legacy one.
Differential Revision: https://reviews.llvm.org/D119195
Many CI runs are very similar in nature. Let's put them into groups for a better overview
Reviewed By: ldionne, #libc
Spies: libcxx-commits, arichardson, mstorsjo
Differential Revision: https://reviews.llvm.org/D119059
Some members are public but should be private. Nothing requires they are public
right now, so make them private.
Differential Revision: https://reviews.llvm.org/D119097
Back in https://reviews.llvm.org/D109459, we stopped using the C++03
emulation for std::nullptr_t by default, which was an ABI break. We
still left a knob for users to turn it back on if they were broken by
the change, with a note that we would remove that knob after one release.
The time has now come to remove the knob and clean up the std::nullptr_t
emulation.
Differential Revision: https://reviews.llvm.org/D114786
containers
Add test cases for iteration over the ordered associative container from
end to begin using operator--
Reviewed By: Quuxplusone, rarutyun
Differential Revision: https://reviews.llvm.org/D118114
This patch makes the uncontrovertial changes to the pipeline.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D119041
Currently GCC produces lots of warnings. Most of them are `-Wattributes`, but these warnings are completly ignored by everybody. So let's disable -Wattributes and make the output cleaner.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D119140
Some `__config` cleanup and `_LIBCPP_ABI_UNSTABLE` should set `_LIBCPP_ABI_VERSION`, since the latest ABI version //is// the unstable ABI.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D118989
To ensure a smooth transition without breaking CI, we should use explicitly
versioned Clangs in the CI jobs definition instead, since that's a change
we can actually test in the CI.
So instead of bumping the compiler version from the Docker image, use
the same version as before by default, and we can bump it from the CI
job definition once all the nodes are running the new image.
Basically a rebase of D104980; most of that patch had already happened
via gradual drive-by changes, but this finishes it up.
Don't touch the inclusions from `<__functional_base>`, `<__hash_table>`,
or `<__locale>`; those could be removed if we propagated the
inclusions up to the includers of those files, but there are lots
of those includers.
`<algorithm>`, `<functional>`, and `<memory>` already include `<utility>`
at the top level. `<iterator>` did not, so I've added it there.
Differential Revision: https://reviews.llvm.org/D119020
var-const points out that `ranges::begin` is (non-normatively
but explicitly) always supposed to return a `std::input_or_output_iterator`,
and `Incomplete*` is not a `std::input_or_output_iterator` because it
has no `operator++`. Therefore, we should never return `Incomplete*`
from `ranges::begin(x)`, even when `x` is `Incomplete(&)[]`. Instead,
just SFINAE away.
Differential Revision: https://reviews.llvm.org/D118963
For some reason `<string>` defines `std::fpos`, which should be defined in `<ios>`.
Reviewed By: Quuxplusone, Mordante, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D118914
It looks like we added some checks to try and use builtin type traits
in https://reviews.llvm.org/D67900, but some of those type traits are
never implemented as builtins, so this is essentially dead code.
Fixes llvm-project#53569
Differential Revision: https://reviews.llvm.org/D118923
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
Louis Dionne