This commit re-adds transitive includes that had been removed by
4cd04d1687, c36870c8e7, a83f4b9cda, 1458458b55, 2e2f3158c6,
and 489637e66d. This should cover almost all the includes that had
been removed since LLVM 14 and that would contribute to breaking user
code when releasing LLVM 15.
It is possible to disable the inclusion of these headers by defining
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will
enable that macro and start fixing downstream issues immediately. We
can then remove the macro (and the transitive includes) by default in
a future release. That way, we will break users only once by removing
transitive includes in bulk instead of doing it bit by bit a every
release, which is more disruptive for users.
Note 1: The set of headers to re-add was found by re-generating the
transitive include test on a checkout of release/14.x, which
provided the list of all transitive includes we used to provide.
Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map>
have been added in this commit. These transitive inclusions were
added when we implemented boyer_moore_searcher in <functional>.
Note 3: This is a best effort patch to try and resolve downstream breakage
caused since branching LLVM 14. I wasn't able to perfectly mirror
transitive includes in LLVM 14 for a few headers, so I added a
release note explaining it. To summarize, adding boyer_moore_searcher
created a bunch of circular dependencies, so we have to break
backwards compatibility in a few cases.
Differential Revision: https://reviews.llvm.org/D128661
Instead of writing every character directly into the container by using
a `back_insert_iterator` the data is buffered in an `array`. This buffer
is then inserted to the container by calling its `insert` member function.
Since there's no guarantee every container's `insert` behaves properly
containers need to opt-in to this behaviour. The appropriate standard
containers opt-in to this behaviour.
This change improves the performance of the format functions that use a
`back_insert_iterator`.
Depends on D110495
Reviewed By: ldionne, vitaut, #libc
Differential Revision: https://reviews.llvm.org/D110497
This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.
It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.
Differential Revision: https://reviews.llvm.org/D122506
In C++20 the type trait `type_identity` was introduced. For the same purpose there is `__identity` for pre-C++20 code. The name is confusing, because since C++20 there is also `identity`, which isn't a type trait.
Reviewed By: ldionne, Mordante, #libc
Spies: EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D122017
Notably the following ctors remain non-explicit because they
are used as implicit conversions in too many places:
* __debug_less(_Compare&)
* __map_iterator(_TreeIterator)
* __map_const_iterator(_TreeIterator)
* __hash_map_iterator(_HashIterator)
* __hash_map_const_iterator(_HashIterator)
Differential Revision: https://reviews.llvm.org/D119894
This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional change: it simply moves
_LIBCPP_ASSERT-related stuff to its own file so as to make it clear that
libc++ assertions and the debug mode are different things. Future patches
will make it possible to enable assertions without enabling the debug
mode.
Differential Revision: https://reviews.llvm.org/D119769
Disable the constructors taking `(size_type, const value_type&,
allocator_type)` if `allocator_type` is not a valid allocator.
Otherwise, these constructors are considered when resolving e.g.
`(int*, int*, NotAnAllocator())`, leading to a hard error during
instantiation. A hard error makes the Standard's requirement to not
consider deduction guides of the form `(Iterator, Iterator,
BadAllocator)` during overload resolution essentially non-functional.
The previous approach was to SFINAE away `allocator_traits`. This patch
SFINAEs away the specific constructors instead, for consistency with
`basic_string` -- see [LWG3076](wg21.link/lwg3076) which describes
a very similar problem for strings (note, however, that unlike LWG3076,
no valid constructor call is affected by the bad instantiation).
Differential Revision: https://reviews.llvm.org/D114311
We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.
Deduction guides for containers should not participate in overload
resolution when called with certain incorrect types (e.g. when called
with a template argument in place of an `InputIterator` that doesn't
qualify as an input iterator). Similarly, class template argument
deduction should not select `unique_ptr` constructors that take a
a pointer.
The tests try out every possible incorrect parameter (but never more
than one incorrect parameter in the same invocation).
Also add deduction guides to the synopsis for associative and unordered
containers (this was accidentally omitted from [D112510](https://reviews.llvm.org/D112510)).
Differential Revision: https://reviews.llvm.org/D112904
Replace `&__rhs` with `_VSTD::addressof(__rhs)` to guard against ADL hijacking
of `operator&` in `operator=`. Thanks to @CaseyCarter for bringing it to our
attention.
Similar issues with hijacking `operator&` still exist, they will be
addressed separately.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D110852
Detected by evil-izing the widely used `MoveOnly` testing type.
I had to patch some tests that were themselves using its comma operator,
but I think that's a worthwhile cost in order to catch more places
in our headers that needed comma-proofing.
The trick here is that even `++ptr, SomeClass()` can find a comma operator
by ADL, if `ptr` is of type `Evil*`. (A comma between two operands
of non-class-or-enum type is always treated as the built-in
comma, without ADL. But if either operand is class-or-enum, then
ADL happens for _both_ operands' types.)
Differential Revision: https://reviews.llvm.org/D109414
I just ran into a compiler error involving __bind_back and some overloads
that were being disabled with _EnableIf. I noticed that the error message
was quite bad and did not mention the reason for the overload being
excluded. Specifically, the error looked like this:
candidate template ignored: substitution failure [with _Args =
<ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>'
Instead, when using enable_if or enable_if_t, the compiler is clever and
can produce better diagnostics, like so:
candidate template ignored: requirement 'is_invocable_v<
std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>,
std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &,
ContiguousView>' was not satisfied [with _Args = <ContiguousView>]
Basically, it tries to do a poor man's implementation of concepts, which
is already a lot better than simply complaining about substitution failure.
Hence, this commit uses enable_if_t instead of _EnableIf whenever
possible. That is both more straightforward than using the internal
helper, and also leads to better error messages in those cases.
I understand the motivation for _EnableIf's implementation was to improve
compile-time performance, however I believe striving to improve error
messages is even more important for our QOI, hence this patch. Furthermore,
it is unclear that _EnableIf actually improved compile-time performance
in any noticeable way (see discussion in the review for details).
Differential Revision: https://reviews.llvm.org/D108216
__split_buffer_common was entirely unused, and __deque_base_common
was unused except for two calls to __throw_out_of_range(), which have
been inlined.
The usual intent of the __xxx_base_common base classes is to localize
where the exception-throwing code is instantiated, however that wasn't
the case here because we never explicitly instantiated those base classes
in the shared library, unlike what we do for basic_string and vector.
Differential Revision: https://reviews.llvm.org/D108384
All supported compilers have supported deduction guides in C++17 for a
while, so this isn't necessary anymore.
Differential Revision: https://reviews.llvm.org/D108213
Moves:
* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
`__algorithm/${FUNCTION_NAME}`
Differential Revision: https://reviews.llvm.org/D103734
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
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
Specifically, use these metafunctions consistently in areas that are
about to be affected by P1518R2's changes.
This is the NFCI part of https://reviews.llvm.org/D97742 .
The functional-change part is still waiting for P1518R2 to be
officially merged into the working draft.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
This reverts commit 620adacf87.
Fix: unsupport C++03 for the new test, define helpers before __swap_allocator
(1) Add _VSTD:: qualification to __swap_allocator.
(2) Add _VSTD:: qualification consistently to __to_address.
(3) Add some more missing _VSTD:: to <vector>, with a regression test.
This part is cleanup after d9a4f936d0.
Note that a vector whose allocator actually runs afoul of any of these ADL calls will
likely also run afoul of simple things like `v1 == v2` (which is also an ADL call).
But, still, libc++ should be consistent in qualifying function calls wherever possible.
Relevant blog post: https://quuxplusone.github.io/blog/2019/09/26/uglification-doesnt-stop-adl/
Differential Revision: https://reviews.llvm.org/D91708
(1) Add _VSTD:: qualification to __swap_allocator.
(2) Add _VSTD:: qualification consistently to __to_address.
(3) Add some more missing _VSTD:: to <vector>, with a regression test.
This part is cleanup after d9a4f936d0.
Note that a vector whose allocator actually runs afoul of any of these ADL calls will
likely also run afoul of simple things like `v1 == v2` (which is also an ADL call).
But, still, libc++ should be consistent in qualifying function calls wherever possible.
Relevant blog post: https://quuxplusone.github.io/blog/2019/09/26/uglification-doesnt-stop-adl/
Differential Revision: https://reviews.llvm.org/D91708
This patch de-duplicates most compressed pair constructors
to use the same code in C++11 and C++03.
Part of doing that is deleting the "__second_tag()" and replacing
it with a "__value_init_tag()" which has the same effect, but
allows for the removal of the special "one-arg" first element
constructor.
This patch is intended to have no semantic change.
With the upcoming introduction of iterator concepts in ranges,
the meaning of "__is_contiguous_iterator" changes drastically.
Currently we intend it to mean "does it have this iterator category",
but it could now also mean "does it meet the requirements of this
concept", and these can be different.
This function has the same behavior as the now-standand std::to_address.
Re-using the name makes the behavior more clear, and in the future it
will allow us to correctly get the raw pointer for user provided pointer
types.
This patch rewrites a few loops in deque and split_buffer to better
optimize the codegen. For constructors like
`deque<unsigned char> d(500000, 0);` this patch results in a 2x speedup.
The patch improves the codegen in roughly three ways:
1. Changes do { ... } while (...) loops into more typical for loops.
The optimizer can reason about normal looking loops better.
2. Split the iteration over a range into (A) iteration over the blocks,
then (B) iteration within the block. This nested structure helps LLVM
lower the inner loop to `memset`.
3. Do fewer things each iteration. Some of these loops were incrementing
or changing 4-5 variables every loop (in addition to the
construction). Previously most loops would increment the end pointer,
the size, and decrement the count of remaining items to construct.
Now we only increment a single pointer for most iterations.
llvm-svn: 368547
I have upcoming changes that modify how deque handles spare blocks.
This cleanup is intended to make those changes easier to review
and understand. This patch should have NFC.
llvm-svn: 367631
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
Also, add tests making sure that vector and deque both catch the problem
when assertions are enabled. Otherwise, deque would segfault and vector
would never terminate.
llvm-svn: 348994
Summary:
The constructors `vector(Iter, Iter, Alloc = Alloc{})` and `assign(Iter, Iter)` don't correctly perform EmplaceConstruction from the result of dereferencing the iterator. This results in them performing an additional and unneeded copy.
This patch addresses the issue by correctly using `emplace_back` in C++11 and newer.
There are also some bugs in our `insert` implementation, but those will be handled separately.
@mclow.lists We should probably merge this into 5.1, agreed?
Reviewers: mclow.lists, dlj, EricWF
Reviewed By: mclow.lists, EricWF
Subscribers: cfe-commits, mclow.lists
Differential Revision: https://reviews.llvm.org/D38757
llvm-svn: 315994
Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.
Reviewers: mclow.lists, bcraig, compnerd, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D33080
llvm-svn: 304357
Nikolas Klauser