`libc++` has had the guarantee of the default constructor of `tuple<>` being
trivial since 405570dc7a. Now, the
standard mandates it as of LWG3211. So, move the file out of
`libcxx/test/libcxx` and into `libcxx/test/std` since it's no longer
`libc++`-specific. Rename it to be `.compile.pass.cpp` instead of
`.pass.cpp` while we're at it.
Reviewed By: ldionne, Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D112743
`is_error_condition_enum_v` and `is_error_code_enum_v` are currently of
type `size_t`, but the standard mandates they are of type `bool`.
This is an ABI break technically since the size of these variable
templates has changed. Document it as such in the release notes.
Fixes https://bugs.llvm.org/show_bug.cgi?id=50755
Reviewed By: ldionne, Quuxplusone, #libc, var-const
Differential Revision: https://reviews.llvm.org/D112553
Add deduction guides to `valarray` and `scoped_allocator_adaptor`. This largely
finishes implementation of the paper:
* deduction guides for other classes mentioned in the paper were
implemented previously (see the list below);
* deduction guides for several classes contained in the proposal
(`reference_wrapper`, `lock_guard`, `scoped_lock`, `unique_lock`,
`shared_lock`) were removed by [LWG2981](https://wg21.link/LWG2981).
Also add deduction guides to the synopsis for the few classes (e.g. `pair`)
where they were missing.
The only part of the paper that isn't fully implemented after this patch is
making sure certain deduction guides don't participate in overload resolution
when given incorrect template parameters.
List of significant commits implementing the other parts of P0433 (omitting some
minor fixes):
* [pair](af65856eec)
* [basic_string](6d9f750dec)
* [array](0ca8c0895c)
* [deque](dbb6f8a817)
* [forward_list](e076700b77)
* [list](4a227e582b)
* [vector](df8f754792)
* [queue/stack/priority_queue](5b8b8b5dce)
* [basic_regex](edd5e29cfe)
* [optional](f35b4bc395)
* [map/multimap](edfe8525de)
* [set/multiset](e20865c387)
* [unordered_set/unordered_multiset](296a80102a)
* [unordered_map/unordered_multimap](dfcd4384cb)
* [function](e1eabcdfad)
* [tuple](1308011e1b)
* [shared_ptr/weak_ptr](83564056d4)
Additional notes:
* It was revision 2 of the paper that was voted into the Standard.
P0433R3 is a separate paper that is not part of the Standard.
* The paper also mandates removing several `make_*_searcher` functions
(e.g. `make_boyer_moore_searcher`) which are currently not implemented
(except in `experimental/`).
* The `__cpp_lib_deduction_guides` feature test macro from the paper was
accidentally omitted from the Standard.
Differential Revision: https://reviews.llvm.org/D112510
Per our support plan we should now support Clang 12 and 13. Adjust the
documentation and the CI runners. The change indirectly moves the main
CI runners to use the Clang 14 nightly builds.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D112360
Mark LWG2731 as complete. The type alias `mutex_type` is only provided if
`scoped_lock` is given one mutex type and it has been implemented that
way since the beginning of Clang 5 it seems. There already are tests for
verifying existence (and lack thereof) for `mutex_type` type alias
depending on the number of mutex types, so there is nothing to
do for this LWG issue.
Reviewed By: Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D112462
Also fix a few places in the `shared_ptr` implementation where
`element_type` was passed to the `__is_compatible` helper. This could
result in `remove_extent` being applied twice to the pointer's template
type (first by the definition of `element_type` and then by the helper),
potentially leading to somewhat less readable error messages for some
incorrect code.
Differential Revision: https://reviews.llvm.org/D112092
Several of our C++20 and C++2b papers were missing the actual revision
number that was voted in to the Standard. The revision number is quite
important because in a few cases, a paper has a revision *after* the
one that is voted into the Standard, which isn't voted into the Standard.
Hence, if we simply followed the wg21.link blindly and implemented that,
we'd end up implementing the latest revision of the paper, which might
not have been voted.
As a fly-by fix, I found out that P1664 had been withdrawn from the
straw polls and had never been voted into the Standard. This commit
removes that entry from our list.
Differential Revision: https://reviews.llvm.org/D112339
`utils/generate_feature_test_macro_components.py` uses the wrong
indentation. `:name: feature-status-table :widths: auto` is rendered as
text instead of being used by Sphinx to render the table properly.
This fixes the identation in the souce and updates the generated output.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D112251
Does anyone still use these? I want to make some changes to the sphinx
html generation and I don't want to have to implement the changes in
two places.
Reviewed By: sylvestre.ledru, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D112030
Mark LWG3573 as complete. It involves a change in wording around when
`basic_string_view`'s constructor for iterator/sentinel can throw. The
current implementation is not marked conditionally `noexcept`, so there
is nothing to do here. Add a test that binds this behavior to verify the
constructor is not marked `noexcept(true)` when `end - begin` throws.
Reviewed By: ldionne, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111925
Mark LWG3420 as complete. Currently, the `cpp17_iterator` concept
checks that the type looks like an iterator first before checking if it
is copyable.
Reviewed By: ldionne, Quuxplusone, #libc
Differential Revision: https://reviews.llvm.org/D111598
Currently the member functions std::allocator<T>::allocate,
std::experimental::pmr::polymorphic_allocator::allocate and
std::resource_adaptor<T>::do_allocate throw an exception of type
std::length_error when the requested size exceeds the maximum size.
According to the C++ standard ([allocator.members]/4,
[mem.poly.allocator.mem]/1), std::allocator<T>::allocate and
std::pmr::polymorphic_allocator::allocate must throw a
std::bad_array_new_length exception in this case.
The patch fixes the issue with std::allocator<T>::allocate and changes
the type the exception thrown by
std::experimental::pmr::resource_adaptor<T>::do_allocate to
std::bad_array_new_length as well for consistency.
The patch resolves LWG 3237, LWG 3038 and LWG 3190.
Reviewed By: ldionne, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D110846
Several entries were in the wrong place, such as API changes appearing
under "Build System Changes". This commit shuffles stuff so it sits under
the right section.
This commit makes the new "runtimes" build (with <monorepo>/runtimes as
the root of the CMake invocation) the default way of building libc++.
The other supported way of building libc++ is the "bootstrapping" build,
where `<monorepo>/llvm` is used as the root of the CMake invocation.
All other ways of building libc++ are deprecated effective immediately.
There should be no use-case for building libc++ that isn't supported by
one of these two builds, and the two new builds work on all environments
and are lightweight. They will also make it possible to greatly simplify
the build infrastructure of the runtimes, which is currently way too
convoluted.
Differential Revision: https://reviews.llvm.org/D111356
A followup to D111458 adding more labels to LWG-issues. This should add
the labels for the not completed chrono, format, ranges, and spaceship
issues.
Some minor formatting cleanups along the way.
Reviewed By: #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D111935
During the review of D111166 I had a private discussion with @ldionne to
avoid the duplication of the C++2b issues in the Ranges and Format
status pages. The main reason for duplicating them is to make it easier to
find them. The title of the paper may not always make it clear to which
project the paper belongs.
This commit removes all LWG-issues from the Ranges and Format status page
and adds labels for these issue in the C++20/C++23 issues list.
A quick scan revealed there are some issues that are missing a label since
they weren't on the ranges issue list. These can be labelled in a separate
commit. In that commit I'll also look for issues for the spaceship operator
and chrono.
Reviewed By: Quuxplusone, ldionne, #libc
Differential Revision: https://reviews.llvm.org/D111458
Implement LWG3480 which enables `directory_iterator` and
`recursive_directory_iterator` to be both a `borrowed_range` and a
`view`.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D111644
Mark LWG3274 as complete. The feature test macro `__cpp_lib_span` was added in
`6d2599e4f776d0cd88438cb82a00c4fc25cc3f67`.
https://wg21.link/p1024 mentions marking `span:::empty()` with
`[[nodiscard]]` which is not done yet. So, do that and add tests.
Reviewed By: ldionne, Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111516
While looking at LWG-2988 and P0558 it seems the issues were already
implemented, but the synopsis wasn't updated. Some of the tests didn't
validate the `noexcept` status. A few tests were missing completely:
- `atomic_wait_explicit`
- `atomic_notify_one`
- `atomic_notify_all`
Mark P0558 as complete, didn't investigate which version of libc++ first
includes this. It seems the paper has been retroactively applied. I
couldn't find whether this is correct, but looking at cppreference it
seems intended.
Completes
- LWG-2988 Clause 32 cleanup missed one typename
- P0558 Resolving atomic<T> named base class inconsistencies
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103765
Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.
Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.
Differential Revision: https://reviews.llvm.org/D111265
Mark LWG3447 as complete since it was not an issue since the original
implementation of `take_view` from
0f4b41e038. Currently, `take_view`'s
deduction guide does not constrain the range on the `range` concept.
Reviewed By: ldionne, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111501
Implement P2401 which adds a `noexcept` specification to
`std::exchange`. Treated as a defect fix which is the motivation for
applying this change to all standards mode rather than just C++23 or
later as the paper suggests.
Reviewed By: Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111481
Implement P2251 which requires `span` and `basic_string_view` to be
trivially copyable. They already are - this just adds tests to bind that
behavior.
Reviewed By: ldionne, Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111197
Implement parts of P1614, including three-way comparison for tuples, and expand testing.
Reviewed By: ldionne, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D108250
Update the status with the approved papers and LWG-issues in the October 2021 plenary.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D111166
While looking at the review comments in D103765 there was an oddity in
the tests for the following functions:
- atomic_fetch_add
- atomic_fetch_add_explicit
- atomic_fetch_sub
- atomic_fetch_sub_explicit
Libc++ allows usage of
`atomic_fetch_add<int>(atomic<int*>*, atomic<int*>::difference_type);`
MSVC and GCC reject this code: https://godbolt.org/z/9d8WzohbE
This makes the atomic `fetch(add|sub).*` Standard conforming and removes the non-conforming extensions.
Fixes PR47908
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D103983
Implements the formatter for Boolean types.
[format.formatter.spec]/2.3
For each charT, for each cv-unqualified arithmetic type ArithmeticT other
than char, wchar_t, char8_t, char16_t, or char32_t, a specialization
```
template<> struct formatter<ArithmeticT, charT>;
```
This removes the stub implemented in D96664.
Implements parts of:
- P0645 Text Formatting
- P1652 Printf corner cases in std::format
Completes:
- P1868 width: clarifying units of width and precision in std::format
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103670
Implements the formatter for all fundamental integer types
(except `char`, `wchar_t`, and `bool`).
[format.formatter.spec]/2.3
For each charT, for each cv-unqualified arithmetic type ArithmeticT other
than char, wchar_t, char8_t, char16_t, or char32_t, a specialization
```
template<> struct formatter<ArithmeticT, charT>;
```
This removes the stub implemented in D96664.
As an extension it adds partial support for 128-bit integer types.
Implements parts of:
- P0645 Text Formatting
- P1652 Printf corner cases in std::format
Completes:
- LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103433
Implement P1391 (https://wg21.link/p1391) which allows
`std::string_view` to be constructible from any contiguous range of
characters.
Note that a different paper (http://wg21.link/P1989) handles the generic
range constructor for `std::string_view`.
Reviewed By: ldionne, Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D110718
This adds the width estimation functions to the std-format-spec.
Implements parts of:
- P0645 Text Formatting
- P1868 width: clarifying units of width and precision in std::format
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103413
Seems this section is not updated since we have transited to llvm-project monorepo.
At the start, we build libcxx under monorepo configuration but later try to make the separate configuration for libcxx build
and running benchmark.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D110722
Implements parts of P1614, including synth-three-way and three way comparison for std::pair.
Reviewed By: #libc, Quuxplusone, Mordante
Differential Revision: https://reviews.llvm.org/D107721
This implements the generic std.format.spec framework for all types.
The Unicode support will be added in a separate patch.
Implements parts of:
- P0645 Text Formatting
Completes:
- LWG-3242 std::format: missing rules for arg-id in width and precision
- P1892 Extended locale-specific presentation specifiers for std::format
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103368
This commit partially reverts 0954e2b2d0 and 3fa4cff974, which
make changes to the libc++ documentation implifying that OpenBSD is
supported. Neither of these changes have been reviewed AFAICT, so
I'm reverting as a matter of enforcing:
1. That changes get reviewed before being committed
2. That we have a discussion and a support plan for supporting
OpenBSD officially in libc++
Please note that I would be thrilled to support OpenBSD officially in
libc++, however doing so requires more than adding a note in the docs.
In particular, please make sure you read the note in [1] about setting
up CI testing for OpenBSD.
[1]: https://libcxx.llvm.org/#platform-and-compiler-support
Differential Revision: https://reviews.llvm.org/D109373
This option is used to select between the format headers output column
width option. This option should be independent of the locale setting.
It's encouraged to default to Unicode unless the platform doesn't offer
that option.
[format.string.std]/10
```
For the purposes of width computation, a string is assumed to be in a
locale-independent, implementation-defined encoding. Implementations
should use a Unicode encoding on platforms capable of displaying Unicode
```
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103379
This implements the initial version of the `std::formatter` class and its specializations. It also implements the following formatting functions:
- `format`
- `vformat`
- `format_to`
- `vformat_to`
- `format_to_n`
- `formatted_size`
All functions have a `char` and `wchar_t` version. Parsing the format-spec and
using the parsed format-spec hasn't been implemented. The code isn't optimized,
neither for speed, nor for size.
The goal is to have the rudimentary basics working, which can be used as a
basis to improve upon. The formatters used in this commit are simple stubs that
will be replaced by real formatters in later commits.
The formatters that are slated to be replaced in this patch series don't have
an availability macro to avoid merge conflicts.
Note the formatter for `bool` uses `0` and `1` instead of "false" and
"true". This will be fixed when the stub is replaced with a real
formatter.
Implements parts of:
- P0645 Text Formatting
Completes:
- LWG3539 format_to must not copy models of output_iterator<const charT&>
Reviewed By: ldionne, #libc, vitaut
Differential Revision: https://reviews.llvm.org/D96664
This implements the struct `__format_arg_store` and its dependencies:
* the class basic_format_arg,
* the class basic_format_args,
* the class basic_format_context,
* the function make_format_args,
* the function wmake_format_args,
* the function visit_format_arg,
* several Standard required typedefs.
The following parts will be implemented in a later patch:
* the child class `basic_format_arg::handle`,
* the function `basic_format_arg::basic_format_arg(const T* p)`.
The following extension has been implemented:
* the class basic_format_arg supports `__[u]int128_t` on platform where libc++ supports 128 bit integrals.
Implements parts of:
* P0645 Text Formatting
Completes:
* LWG3371 visit_format_arg and make_format_args are not hidden friends
* LWG3542 basic_format_arg mishandles basic_string_view with custom traits
Note https://mordante.github.io/blog/2021/06/05/format.html gives a bit more information about the goals and non-goals of this initial patch series.
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103357
Feature test macro for `__cpp_lib_is_nothrow_convertible` was introduced in
466df1718e but the LWG issue was not marked as
`Complete` in the docs. Also, fix the formatting of `Complete` for
LWG 3348.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D108964
Mark LWG3348 as complete. The `__cpp_lib_unwrap_ref` feature test macro
was placed in `<functional>` in 466df1718e
Differential Revision: https://reviews.llvm.org/D108920
Mark the now-done [cmp.result] in spaceship projects as complete;
normalize some status markers for papers and projects; fix alignment
and line breaks in spaceship projects, add links to standard
Differential Revision: https://reviews.llvm.org/D108502
Based on https://github.com/NuxiNL/cloudlibc, it appears that the CloudABI
project has been abandoned. This patch removes a bunch of CloudABI specific
logic that had been added to support that platform.
Note that some knobs like LIBCXX_ENABLE_STDIN and LIBCXX_ENABLE_STDOUT
coud be useful in their own right, however those are currently broken.
If we want to re-add such knobs in the future, we can do it like we've
done it for localization & friends so that we can officially support
that configuration.
Differential Revision: https://reviews.llvm.org/D108637
Add issue tracking and assignment for the implementation of P1614R2: The Mothership has Landed.
Reviewed By: cjdb, #libc, Mordante, Quuxplusone
Differential Revision: https://reviews.llvm.org/D107877
We just had a case where a build bot stalled in an infinite loop during
testing, and the whole pipeline got stuck. To avoid that from happening
in the future, use a timeout on BuildKite jobs.
Differential Revision: https://reviews.llvm.org/D107765
Shorty before branching LLVM 13 a new CMake option was added. This
option `LIBCXX_ENABLE_INCOMPLETE_FEATURES` lacks the contributor
documentation. This patch rectifies that issue.
Differential Revision: https://reviews.llvm.org/D107596
Implement the changes in all language modes.
LWG3506 "Missing allocator-extended constructors for priority_queue"
makes the following changes:
- New allocator-extended constructors for priority_queue.
- New deduction guides targeting those constructors.
LWG3522: "Missing requirement on InputIterator template parameter
for priority_queue constructors". The iterator parameter should be
constrained to actually be an iterator type. `priority_queue{1,2}`
should be SFINAE-friendly ill-formed.
Also, do a drive-by fix in the allocator-extended move constructor:
there's no need to do a `make_heap` after moving from `__q.c` into
our own `c`, because that container was already heapified when it
was part of `__q`. [priqueue.cons.alloc] actually specifies the
behavior and does *not* mention calling `make_heap`. I think this
was just a copy-paste thinko. It dates back to the initial import
of libc++.
Differential Revision: https://reviews.llvm.org/D106824
Differential Revision: https://reviews.llvm.org/D106827
Adds a new CMake option to disable the usage of incomplete headers.
These incomplete headers are not guaranteed to be ABI stable. This
option is intended to be used by vendors so they can avoid their users
from code that's not ready for production usage.
The option is enabled by default.
Differential Revision: https://reviews.llvm.org/D106763
Updates the status pages with the LWG issues accepted in the Standard
during the June 2021 plenary session. The LWG papers for this meeting
have been added in D105103.
Differential Revision: https://reviews.llvm.org/D106529
We've been forgetting to add those to most of the <ranges> review.
To avoid forgetting in the future, I added an item in the pre-commit
checklist.
Differential Revision: https://reviews.llvm.org/D106287
As we automate more and more things in the library, it becomes useful for
contributors to have a single target for running all the automation as
part of their workflow. This commit adds a new `libcxx-generate-files`
target that should re-generate all the auto-generated files in the library.
As a fly-by, I also revamped the documentation on Contributing to account
for this new target and present it as a bullet list of things to check
before committing. I also added a few things that are often overlooked
to that list, such as updating the synopsis and the status files.
Differential Revision: https://reviews.llvm.org/D106067
This is a second attempt at D101497, which landed as
9a9bc76c0e but had to be reverted in
8cf7ddbdd4.
This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is
empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to
"/bin" not "bin" as intended and as was originally.
One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty,
defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach.
But, I think it is more ergonomic to allow those project-specific paths
to be relative the global ones. Also, making install paths absolute by
default inhibits the proper behavior of functions like
`GNUInstallDirs_get_absolute_install_dir` which make relative install
paths absolute in a more complicated way.
Given all this, I will define a function like the one asked for in
https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a
similar use-case).
---
Original message:
Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for
complier-rt, just use it to define variables for the subdirs which
themselves are used.
This preserves compatibility, but later on we might consider getting rid
of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the
subdir variables directly.
---
There was a seaming bug where the (non-Apple) per-target libdir was
`${target}` not `lib/${target}`. I suspect that has to do with the docs
on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no
longer true, so I just went ahead and fixed it, allowing me to define
fewer and more sensible variables.
That last part should be the only behavior changes; everything else
should be a pure refactoring.
---
I added some documentation of these variables too. In particular, I
wanted to highlight the gotcha where `-DSomeCachePath=...` without the
`:PATH` will lead CMake to make the path absolute. See [1] for
discussion of the problem, and [2] for the brief official documentation
they added as a result.
[1]: https://cmake.org/pipermail/cmake/2015-March/060204.html
[2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options
In 38b2dec37e the problem was somewhat
misidentified and so `:STRING` was used, but `:PATH` is better as it
sets the correct type from the get-go.
---
D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands,
it should be feasible to follow both of these up with a simple patch for
compiler-rt analogous to the one for libcxx.
Reviewed By: phosek, #libc_abi, #libunwind
Differential Revision: https://reviews.llvm.org/D105765
This will allow us to use variant in common_iterator. We do this by introducing a new `__light_array` type that variant uses instead of `std::array`.
Differential Revision: https://reviews.llvm.org/D105597
This patch overhauls the documentation around building libc++
for vendors, and using libc++ for end-users. It also:
- Removes mention of the standalone build, which we've been trying to
get rid of for a long time.
- Removes mention of using a local ABI installation, which we don't do
and is documented as "not recommended".
- Removes mention of the separate libc++filesystem.a library, which isn't
relevant anymore since filesystem support is in the main library.
- Adds mention of the GDB pretty printers and how to use them.
The various design docs have been moved to RST, and the linked blog post
does not apply anymore since libc++ is the default library used by Clang
on Apple platforms.
* indicates whether work has been started or completed
* consolidates content that was split for dependency reasons (iff
everything has been merged)
* makes things a lot more fine-grained
* turns sub-CSVs into lists
* puts links into description section and removes patch column
* adds links to c++draft on occasion
These changes heavily prioritise the the reader of the generated HTML
file, not the source.
Differential Revision: https://reviews.llvm.org/D103295
P1518 does the following in C++23 but we'll just do it in C++17 as well:
- Stop requiring `Alloc` to be an allocator on some container-adaptor deduction guides
- Stop deducing from `Allocator` on some sequence container constructors
- Stop deducing from `Allocator` on some other container constructors (libc++ already did this)
The affected constructors are the "allocator-extended" versions of
constructors where the non-allocator arguments are already sufficient
to deduce the allocator type. For example,
std::pmr::vector<int> v1;
std::vector v2(v1, std::pmr::new_delete_resource());
std::stack s2(v1, std::pmr::new_delete_resource());
Differential Revision: https://reviews.llvm.org/D97742
While the std::allocator<void> specialization was deprecated by
https://wg21.link/p0174#2.2, the *use* of std::allocator<void> by users
was not. The intent was that std::allocator<void> could still be used
in C++17 and C++20, but starting with C++20 (with the removal of the
specialization), std::allocator<void> would use the primary template.
That intent was called out in wg21.link/p0619r4#3.9.
As a result of this patch, _LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS
will also not control whether the explicit specialization is provided or
not. It shouldn't matter, since in C++20, one can simply use the primary
template.
Fixes http://llvm.org/PR50299
Differential Revision: https://reviews.llvm.org/D104323
Instead, people should be using CMAKE_POSITION_INDEPENDENT_CODE to control
whether they want to use PIC or not. We should try to avoid reinventing
the wheel whenever CMake natively supports something.
This makes libc++abi consistent with libc++ and libunwind.
Differential Revision: https://reviews.llvm.org/D103973
Makes the following operations constexpr:
* `std::swap(optional, optional)`
* `optional(optional<U> const&)`
* `optional(optional<U>&&)`
* `~optional()`
* `operator=(nullopt_t)`
* `operator=(U&&)`
* `operator=(optional<U> const&)`
* `operator=(optional<U>&&)`
* `emplace(Args&&...)`
* `emplace(initializer_list<U>, Args&&...)`
* `swap(optional&)`
* `reset()`
P2231 has been accepted by plenary, with the committee recommending
implementers retroactively apply to C++20. It's necessary for us to
implement _`semiregular-box`_ and _`non-propagating-cache`_, both of
which are required for ranges (otherwise we'll need to reimplement
`std::optional` with these members `constexpr`ified).
Differential Revision: https://reviews.llvm.org/D102119
The post-conditions for the self move assignment of `std::unique_ptr`
were changed. This requires no implementation changes. A test was added
to validate the new post-conditions.
Addresses
- LWG-3455: Incorrect Postconditions on `unique_ptr` move assignment
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103764
This commit finishes moving the <atomic> design documents to the RST
documentation and removes the old documentation. https://libcxx.llvm.org
is already pointing to the new documentation only now, so the removal of
the old documentation is really a NFC.
I went over the old documentation and I don't think we're leaving anything
important behind - I think everything important was mentionned in the RST
documentation anyway.
This also provides some of the scaffolding needed by D102992 and D101729, and mops up after D101730 etc.
Differential Revision: https://reviews.llvm.org/D103055
- Fixes paper number P1862 -> P1868. (The title was correct.)
- Marks P1868 as in progress.
- Marks P1892 as in progress.
- Marks LWG-3327 as nothing to do, since the wording change doesn't
impact the code. (Also updated on the general C++20 status page.)
* adds `sized_range` and conformance tests
* moves `disable_sized_range` into namespace `std::ranges`
* removes explicit type parameter
Implements part of P0896 'The One Ranges Proposal'.
Differential Revision: https://reviews.llvm.org/D102434
This fixes a long standing issue where the triple is not always set
consistently in all configurations. This change also moves the
back-deployment Lit features to using the proper target triple
instead of using something ad-hoc.
This will be necessary for using from scratch Lit configuration files
in both normal testing and back-deployment testing.
Differential Revision: https://reviews.llvm.org/D102012
`__debug_less` ends up running the comparator up-to-twice per comparison,
because whenever `(x < y)` it goes on to verify that `!(y < x)`.
This breaks the strict "Complexity" guarantees of algorithms like
`inplace_merge`, which we test in the test suite. So, just skip the
complexity assertions in debug mode.
Differential Revision: https://reviews.llvm.org/D101677
This patch gets rid of technical debt around std::pointer_safety which,
I claim, is entirely unnecessary. I don't think anybody has used
std::pointer_safety in actual code because we do not implement the
underlying garbage collection support. In fact, P2186 even proposes
removing these facilities entirely from a future C++ version. As such,
I think it's entirely fine to get rid of complex workarounds whose goals
were to avoid breaking the ABI back in 2017.
I'm putting this up both to get reviews and to discuss this proposal for
a breaking change. I think we should be comfortable with making these
tiny breaks if we are confident they won't hurt anyone, which I'm fairly
confident is the case here.
Differential Revision: https://reviews.llvm.org/D100410
A status page for libc++'s Format library. The page is inspired by
@zoecarver's Ranges status page.
Differential Revision: https://reviews.llvm.org/D101085
This nasty patch rewrites the tuple constructors to match those defined
by the Standard. We were previously providing several extensions in those
constructors - those extensions are removed by this patch.
The issue with those extensions is that we've had numerous bugs filed
against us over the years for problems essentially caused by them. As a
result, people are unable to use tuple in ways that are blessed by the
Standard, all that for the perceived benefit of providing them extensions
that they never asked for.
Since this is an API break, I communicated it in the release notes.
I do not foresee major issues with this break because I don't think the
extensions are too widely relied upon, but we can ship it and see if we
get complaints before the next LLVM release - that will give us some
amount of information regarding how much use these extensions have.
Differential Revision: https://reviews.llvm.org/D96523
Implements parts of:
* P0896R4 The One Ranges Proposal
Depends on D99855.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D99863
Kazu Hirata