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
This is the initial patch to implement ranges in libc++.
Implements parts of:
- P0896R4 One Ranges Proposal
- P1870 forwarding-range is too subtle
- LWG3379 in several library names is misleading
Reviewed By: ldionne, #libc, cjdb, zoecarver, Quuxplusone
Differential Revision: https://reviews.llvm.org/D90999
This patch fixes LWG2874. It is based on the original patch by Zoe Carver
originally uploaded at D81417.
Differential Revision: https://reviews.llvm.org/D81417
Implements parts of:
* P0896R4 The One Ranges Proposal
* LWG3446 `indirectly_readable_traits` ambiguity for types with both `value_type` and `element_type`
Depends on D99141.
Differential Revision: https://reviews.llvm.org/D99461
The added documents have two tables: 1 containing links to issues and papers related to ranges. And the other contains most of the sections from the One Ranges Proposal, with their dependencies linked. This will allow us to assign work that can be done in parallel.
Differential Revision: https://reviews.llvm.org/D100393
These [[nodiscard]] annotations are added as a conforming extension;
it's unclear whether the paper will actually be adopted and make them
mandatory, but they do seem like good ideas regardless.
https://isocpp.org/files/papers/D2351R0.pdf
This patch implements the paper's effect on:
- std::to_integer, std::to_underlying
- std::forward, std::move, std::move_if_noexcept
- std::as_const
- std::identity
The paper also affects (but libc++ does not yet have an implementation of):
- std::bit_cast
Differential Revision: https://reviews.llvm.org/D99895
After this patch, we can use `--param std=c++20` even if the compiler only
supports -std=c++2a. The test suite will handle that for us. The only Lit
feature that isn't fully baked will always be the "in development" one,
since we don't know exactly what year the standard will be ratified in.
This is another take on https://reviews.llvm.org/D99789.
Differential Revision: https://reviews.llvm.org/D100210
The document has the following updates:
- Rename 'feature test' to 'feature-test', the latter is the spelling
used in the Standard.
- Add information how an ABI list can be downloaded from Buildkite.
Differential Revision: https://reviews.llvm.org/D99290
LWG3175 identifies that the `common_reference` requirement for
`swappable_with` is over-constraining and doesn't need to concern itself
with cv- or reference qualifiers.
Differential Revision: https://reviews.llvm.org/D99817
As mandated by the Standard's various synopses, e.g. [iterator.synopsis].
Searching the TeX source for '#include' is a good way to find all of these
mandates.
The new tests are all autogenerated by utils/generate_header_inclusion_tests.py.
I was SHOCKED by how many mandates there are, and how many of them
libc++ wasn't conforming with.
Differential Revision: https://reviews.llvm.org/D99309
* `std::predicate`
* `std::relation`
* `std::equivalence_relation`
* `std::strict_weak_order`
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Differential Revision: https://reviews.llvm.org/D96477
These variables were introduced during early work on the runtimes build
but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR.
Differential Revision: https://reviews.llvm.org/D99697
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
Differential Revision: https://reviews.llvm.org/D97572
This patch changes the variant even in pre-C++2b.
It should not break anything, only allow use cases that didn't work previously.
Notes:
`__as_variant` is used in `__visitation::__variant::__visit_alt`, but I haven't used it in `__visitation::__variant::__visit_alt_at`.
That's because it is used only in `__visit_value_at`, which in turn is always used on variant specializations (that's in comparison operators).
* https://wg21.link/P2162
Reviewed By: ldionne, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D97394
Refresh the existing paragraphs on building in MSVC configurations,
add a sample of one working configuration for MinGW, and add more
details on what's necessary to run the tests these days.
Differential Revision: https://reviews.llvm.org/D97166
This patch ensures that SFINAE is used to delete assignment operators in pair and tuple based on issue 2729.
Differential Review: https://reviews.llvm.org/D62454
This patch implements 2802. Requires _Deleter to have call operator and be move constructible. Based on D62233.
Refs PR37637.
Differential Revision: https://reviews.llvm.org/D62274
Implement the resolution of LWG2993. Replace a deleted constructor
with a constructor that SFINAEs away in appropriate circumstances.
Also, now that the constructor is templated, we must have an
explicit deduction guide to make CTAD work.
Some tests have been merged in from Agustín Bergé's D40259.
Differential Revision: https://reviews.llvm.org/D92725
Some work-in-progress patches for the format header contain benchmarks.
The format header requires C++20 to build. This is a preparation to make
it easy to add these benchmarks.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D96057
Adds documentation around libc++'s policy to add noexcept to things that cannot throw but aren't marked as noexcept.
Refs LWG 3518 and D95251.
Differential Revision: https://reviews.llvm.org/D95821
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
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
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
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
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
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.
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
* 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
Arthur O'Dwyer