We do ship those headers, so the directory name should not be something
that can potentially conflict with user-defined directories.
Differential Revision: https://reviews.llvm.org/D95956
- Implement C++20's changes to `reverse_iterator`, so that it won't be
accidentally counted as a contiguous iterator in C++20 mode.
- Implement C++20's changes to `move_iterator` as well.
- `move_iterator` should not be contiguous. This fixes a bug where
we optimized `std::copy`-of-move-iterators in an observable way.
Add a regression test for that bugfix.
- Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant
standard iterator types. Particularly check that vector::iterator
is still considered contiguous in all C++ modes, even C++03.
After this patch, there continues to be no supported way to write your
own iterator type in C++17-and-earlier such that libc++ will consider it
"contiguous"; however, we now fully support the C++20 approach (in C++20
mode only). If you want user-defined contiguous iterators in C++17-and-earlier,
libc++'s position is "please upgrade to C++20."
Differential Revision: https://reviews.llvm.org/D94807
This will allow running back-deployment testing on macOS only on systems
running the right version of macOS. For the time being, we're cheating
because we don't have actual machines running older than 10.15.
This reverts commit 35a57f39b5.
A build is broken during clang bootstrap with:
In file included from ../libcxx/src/format.cpp:9:
/tmp/ci-nGNyLRM9V3/include/c++/v1/format:153:16: error: no member named 'is_constant_evaluated' in namespace 'std::__1'
if (_VSTD::is_constant_evaluated() && __id >= __num_args_)
~~~~~~~^
1 error generated.
Implements:
- LWG3149 DefaultConstructible should require default initialization
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Depends on D91986
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93461
Add deleted volatile copy-assignment operator in the most derived atomic
to fix the Bug 41784. The root cause: there is an `operator=(T) volatile`
that has better match than the deleted copy-assignment operator of the base
class when `this` is `volatile`. The compiler sees that right operand of
the assignment operator can be converted to `T` and chooses that path
without taking into account the deleted copy-assignment operator of the
base class.
The current behavior on libstdc++ is different from what we have in libc++.
On the same test compilation fails with libstdc++. Proof: https://godbolt.org/z/nebPYd
(everything is the same except the -stdlib option).
I choose the way with explicit definition of copy-assignment for atomic
in the most derived class. But probably we can fix that by moving
`operator=(T)` overloads to the base class from both specializations.
At first glance, it shouldn't break anything.
Differential Revision: https://reviews.llvm.org/D90968
After committing D92214 it was noticed libc++ no longer builds with
C++17. For now reenable building with C++17. This is intended to be a
temporary measure in the future a C++20 capable compiler will be
required.
The MS STL does even more cleanup (corresponding to lexically_normal
I think), but this seems to be the very minimum needed for making the
symlinks work when the target path contains non-native paths.
Differential Revision: https://reviews.llvm.org/D91145
Use the corresponding wchar functions, named "_wfunc" instead of "func",
where feasible, or reimplement functions with native windows APIs.
Differential Revision: https://reviews.llvm.org/D91143
While the windows CRTs (the modern UCRT, and the legacy msvcrt.dll
that mingw still often defaults to) do provide stat functions, they're
a bit lacking - they only provide second precision on the modification
time, lack support for symlinks and a few other details.
Instead reimplement them using a couple windows native functions,
getting exactly the info we need. (Technically, the implementation
within the CRT calls these functions anyway.)
If we only need a few fields, we could also do with fewer calls, as a
later optimization.
Differential Revision: https://reviews.llvm.org/D91141
... so that comparisons with an `int` LHS and `MoveOnly` RHS are valid, as is necessary for the `partial_sort_copy` test to pass with an implementation that doesn't force a conversion to the type of the RHS as libc++ does.
P1614R2 removes most of `directory_entry`'s member comparison operators, leaving only `operator==` and `operator<=>`. This test should require the comparison expressions to be valid rather than require the member functions to be present so it is correct in both C++17 and C++20 modes.
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Depends on: D91004
Reviewed By: ldionne, cjdb, #libc
Differential Revision: https://reviews.llvm.org/D91986
This is the first step at implementing <format>. It adds the <format> header
and implements the `format_error`. class.
Implemnts parts of:
-P0645 Text Formatting
Reviewed By: ldionne, #libc, miscco, curdeius
Differential Revision: https://reviews.llvm.org/D92214
This patch is more than just adding the `constexpr` keyword, because
the old code relied on `goto`, and `goto` is not constexpr-friendly.
Refactor to eliminate `goto`, and then mark it as constexpr in C++20.
I freely admit that the name `__nth_element_partloop` is bad;
I couldn't find any better name because I don't really know
what this loop is doing, conceptually. Vice versa, I think
`__nth_element_find_guard` has a decent name.
Now the only one we're still missing from P0879 is `sort`.
Differential Revision: https://reviews.llvm.org/D93557
https://reviews.llvm.org/rG5369517d20dd362a178a1b2d6c398d8898ee4620
bumped the version number in __config to 13000, causing a test failure
in libcxx/test/libcxx/libcpp_version.pass.cpp because now the two
don't match.
This is the only part of the post-release TODO in
libcxx/docs/Contributing.rst that wasn't done by that commit.
LWG reflector consensus is that this was a bug in libc++.
(In particular, MSVC also will fix it in their STL, soon.)
Bug originally discovered by Logan Smith.
Also fix `std::function<const void()>`, which should work
the same way as `std::function<void()>` in terms of allowing
"conversions" from non-void types.
Differential Revision: https://reviews.llvm.org/D94452
After this patch, the only parts of P0879 that remain missing will be
std::nth_element, std::sort, and the heap/partial_sort algorithms.
Differential Revision: https://reviews.llvm.org/D93443
Defining PATH_MAX to _XOPEN_PATH_MAX which is the closest macro available on z/OS.
Note that this value is 1024 which is 4 times smaller from same macro on Linux.
Reviewed By: #libc, ldionne, hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D92110
During the review of D91986 it has been discovered the in C++11
deprecated `throw()` exception specification has been removed in
C++20. Removed the part of the test code using this feature.
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Reviewed By: ldionne, miscco, #libc
Differential Revision: https://reviews.llvm.org/D91004
It has the low-level bit fiddling operations from bit. It eliminates a cyclic dependency between __bit_reference, bits, and vector. I want to exploit this in later patches.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D94908
local __libcpp_asprintf_l() -> libc asprintf() was inspecting the pointer (with
indeterminate value) for failure, rather than the return value of -1.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D94564
Currently all these tests are XFAILED on Linux even though the problem
only seems to be with the few checks that look at collation. To retain
test coverage this splits the locale-dependent tests into a separate
.pass.cpp that is XFAILed as before.
This commit also XFAILs the locale-dependent tests on FreeBSD since the
[=M=] and [.ch.] behaviour for cs_CZ also doesn't seem to match the
behaviour that is expected by these tests.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D94969
Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem
support was compiled into libc++'s library. This commit promotes the
setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where
the whole library is aware of the setting and features that depend on
<filesystem> won't be provided at all. The test suite is also properly
annotated such that tests that depend on <filesystem> are disabled when
the library doesn't support it.
This is an alternative to https://llvm.org/D94824, but also an improvement
along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to
make for a while.
Differential Revision: https://reviews.llvm.org/D94921
When the Debug mode is enabled, we disable extern declarations because we
don't want to use the functions compiled in the library, which might not
have had the debug mode enabled when built. However, some extern declarations
need to be kept, because code correctness depends on it.
31e820378b removed those declarations, which had the unintended
consequence of breaking the debug build. This commit fixes that by
re-introducing a separate macro for the required extern declarations,
and adds a comment so that we don't fall into that trap in the future.
Differential Revision: https://reviews.llvm.org/D94718
cmake_minimum_required(VERSION) calls cmake_policy(VERSION),
which sets all policies up to VERSION to NEW.
LLVM started requiring CMake 3.13 last year, so we can remove
a bunch of code setting policies prior to 3.13 to NEW as it
no longer has any effect.
Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D94374
The implementation had a lot of boilerplate and was more complicated than
necessary. This NFC refactoring introduces a few macros to reduce code
duplication, and uses a consistent style and formatting for the whole file.
Differential Revision: https://reviews.llvm.org/D94544
I've been playing a bit with the `generate_feature_test_macro_components.py` script and replaced some hardcoded values with extra code generation (generate ALL the things).
The output is the same and it makes updating the script less work for the coming 25 C++ standards (until 2 digit number overflow).
Feel free to 'veto' if you think it's overkill.
Differential Revision: https://reviews.llvm.org/D94530
Several subprojects have targets that do the same thing, and they all
follow the same naming convention: llvm-test-depends, clang-test-depends,
lld-test-depends, etc.
This makes libc++ consistent with other LLVM projects.
Thanks to Duncan Exon Smith for noticing and suggesting the change.
Differential Revision: https://reviews.llvm.org/D94499
Clang insists that __attribute__ attributes precede __declspec
attributes. This is a longstanding known issue:
https://llvm.org/pr24559. Re-order the visibility and deprecation macros
to fix the build.
Differential Revision: https://reviews.llvm.org/D94788
If mutex::try_lock() is called in a thread that already owns the mutex,
the behavior is undefined. The patch fixes the issue by creating another
thread, where the call is allowed.
Differential Revision: https://reviews.llvm.org/D94656
Contrary to the current visibility macro documentation, it appears that
gcc does handle visibility attribute on extern templates correctly, e.g.
https://godbolt.org/g/EejuV7. We need this so that extern template
instantiations of classes not marked _LIBCPP_TEMPLATE_VIS (e.g.
__vector_base_common) are correctly exported with gcc when building with
hidden visibility.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D35388
Sometimes `_Compare` is an lvalue reference type, so letting it be
deduced is pretty much always wrong. (Well, less efficient than
it could be, anyway.)
Differential Revision: https://reviews.llvm.org/D93562
This adds `// clang-format off` in the auto-generated file to avoid lint warnings.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D94410
The point of LWG2511 is basically just to make sure that we use
`tuple<Args&&...>` instead of `tuple<Args...>` in a couple of places
inside `scoped_allocator_adaptor` and inside `pair`.
As far as I can tell, this has been true for libc++
since EricWF's D27612 (and maybe even earlier than that).
I accidentally disabled this feature-test macro in my D93830,
due to a rebasing conflict. It had been enabled by my D93815,
and should have remained enabled.
In 7cd67904f7, we removed the unnecessary nullptr checks from the libc++abi
definition of operator delete, but we forgot to update the definition in
libc++ (damn code duplication!). Then, in d4a1e03c5f, I synced the
definitions across libc++ and libc++abi, but I did it the wrong way around.
I re-added the if() checks to libc++abi instead of removing them from libc++.
In ef74f0fdc3, we re-removed the if() check from operator delete, but
only in libc++abi. This patch corrects this mess and removes it
consistently in libc++ and libc++abi.
Differential Revision: https://reviews.llvm.org/D93473
This patch updates `allocate_shared` to call `allocator_traits::construct`
when creating the object held inside the shared_pointer, and
`allocator_traits::destroy` when destroying it. This resolves
the part of P0674R1 that was originally filed as LWG2070.
This change is landed separately from the rest of P0674R1 because it is
incredibly tricky from an ABI perspective.
This is the reason why this change is so tricky is that we previously
used EBO in a compressed pair to store both the allocator and the object
type stored in the `shared_ptr`. However, starting in C++20, P0674
requires us to use Allocator construction for initializing the object type.
That requirement rules out the use of the EBO for the object type, since
using the EBO implies that the base will be initialized when the control
block is initialized (and hence we can't do it through Allocator construction).
Hence, supporting P0674 requires changing how we store the object type
inside the control block, which we do while being ABI compatible by using
some trickery with a properly aligned char buffer.
Fixes https://llvm.org/PR41900
Supersedes https://llvm.org/D62760
Differential Revision: https://reviews.llvm.org/D91201
It's still a little confusing because in many cases C++17 and C++20
have different values, and libc++ implements the C++17 behavior but
not the C++20 behavior; 'unimplemented' can't represent that scenario.
Ultimately we probably ought to completely redesign the script to be
in terms of paper numbers, rather than language revisions, and make
it generate the CSV files like "Cxx2aStatusPaperStatus.csv" as well.
Most newly added macros are unimplemented. I've marked a few as implemented,
though, based on my reading of the code; for example I was pretty sure
`__cpp_lib_latch` is implemented since we have `<latch>`.
Differential Revision: https://reviews.llvm.org/D93830
FreeBSD did not provide the __atomic_* functions as part of the base
system until recently. They were added to libgcc_s in SVN revision r364753
(August 2020), so check for availability of 'non-lockfree-atomics' so that
these tests do not fail unexpectedly on older versions of FreeBSD.
This also removes the #ifndef __APPLE__ from atomic_helpers.h that was used
to work around lack of atomic runtime functions on older Apple platforms
and replaces it with XFAIL: !non-lockfree-atomics.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88818
* The only exception is that the flag -std=c++2a is still used not to break compatibility with older compilers (clang <= 9, gcc <= 9).
* Bump _LIBCPP_STD_VER for C++20 to 20 and use 21 for the future standard (C++2b).
That's a preparation step to add c++2b support to libc++.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93383
The nullptr_t_integral_cast.pass.cpp test is currently xfailed for
C++03, but actually, it only fails with the first version of libc++
ABI.
This patch changes XFAIL to UNSUPPORTED to avoid unexpected passes
with ABI v2 or later.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93941
This affects only vectors with weird/malicious allocators,
the same corner case covered in D91708, but for `vector<bool>` this time.
Also ADL-proof <__tree>, which affects only sets and maps with weird/malicious
allocators where the ADL trap is in the *fancy pointer type*.
Also drive-by _VSTD:: qualification in the guts of std::bind,
std::packaged_task, std::condition_variable.
Differential Revision: https://reviews.llvm.org/D93424
"LLVM Buildbot on libcxx-libcxxabi-x86_64-linux-debian" is not happy
with default-initializing the `double` member of `A` in a constexpr
function. At least I'm pretty sure that's what it's complaining about.
On macOS 10.14 /usr/lib/system/libcompiler_rt.dylib contains all the
`__atomic_load*`, etc. functions but does not include the `__atomic_is_lock_free`
function. The lack of this function causes the non-lockfree-atomics feature
to be set to false even though large atomic operations are actually
supported, it's just the is_lock_free() function that is missing.
This is required so that the !non-lockfree-atomics feature can be used
to XFAIL tests that require runtime library support (D88818).
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D91911
The directory_iterator.cpp file did contain an incomplete,
non-working implementation for windows.
Change it to use the wchar version of the APIs.
Don't set the windows specific errors from GetLastError() as code
in the generic category; remap the errors to the std::errc values.
Error out cleanly on empty paths.
Invoke FindFirstFile on <directoryname>/* to actually list the
entries of the directory.
If the first entry retured by FindFirstFile is to be skipped (e.g.
being "." or ".."), call advance() (which calls FindNextFile and loops)
which doesn't return until a valid entry is found (or the end is
reached).
Differential Revision: https://reviews.llvm.org/D91140
On windows, the narrow, char based paths normally don't use utf8, but
can use many different native code pages, and this is what system
functions that operate on files, taking such paths/file names, interpret
them as.
Differential Revision: https://reviews.llvm.org/D91137
Also set the preferred separator to backslash.
libc++ doesn't compile successfully for windows prior to this change,
and this change on its own isn't enough to make it compile successfully
either, but is the first stepping stone towards making it work correctly.
Most of operations.cpp will need to be touched, both for calling
functions that take wchar paths, but also for using other windows
specific functions instead of the posix functions used so far; that is
handled in later commits.
Changing parts of operations.cpp to generalize the string type handling
in code that doesn't touch system functions.
Differential Revision: https://reviews.llvm.org/D91135
Louis Dionne