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
The debug mode has been broken pretty much ever since it was shipped
because it was possible to enable the debug mode in user code without
actually enabling it in the dylib, leading to ODR violations that
caused various kinds of failures.
This commit makes the debug mode a knob that is configured when
building the library and which can't be changed afterwards. This is
less flexible for users, however it will actually work as intended
and it will allow us, in the future, to add various kinds of checks
that do not assume the same ABI as the normal library. Furthermore,
this will make the debug mode more robust, which means that vendors
might be more tempted to support it properly, which hasn't been the
case with the current debug mode.
This patch shouldn't break any user code, except folks who are building
against a library that doesn't have the debug mode enabled and who try
to enable the debug mode in their code. Such users will get a compile-time
error explaining that this configuration isn't supported anymore.
In the future, we should further increase the granularity of the debug
mode checks so that we can cherry-pick which checks to enable, like we
do for unspecified behavior randomization.
Differential Revision: https://reviews.llvm.org/D122941
Instead of providing two different constructors for iterators that
support the debug mode, provide a single constructor but leave the
container parameter unused when the debug mode is not enabled.
This allows simplifying all the call sites to unconditionally pass
the container, which removes a bunch of duplication in the container's
implementation.
Note that this patch does add some complexity to std::span, however
that is only because std::span has the ability to use raw pointers
as iterators instead of __wrap_iter. In retrospect, I believe it was
a mistake to provide that capability, and so it will be removed in a
future patch, along with the complexity added by this patch.
Differential Revision: https://reviews.llvm.org/D126993
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
I audited all uses of _LIBCPP_ASSERT to make sure that we only used it
for "basic assertions", i.e. assertions with constant-time conditions.
I also audited all uses of _LIBCPP_DEBUG_ASSERT to make sure we used it
only for debug-mode assertions, and in one case had to change for
_LIBCPP_ASSERT instead.
As a fly-by, I also changed a couple of tests against nullptr or 0 to
be more explicit.
After this patch, all uses of _LIBCPP_ASSERT should be with constant-time
conditions, and all uses of _LIBCPP_DEBUG_ASSERT should be with conditions
that we only want to check when the debug mode is enabled.
Differential Revision: https://reviews.llvm.org/D122395
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
There are a lot of
```
#if _LIBCPP_DEBUG_LEVEL == 2
__get_db()->__insert_c(this);
#endif
```
This patch introduces `__debug_db_insert_c()` to put the `#if` in one central place.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D116947
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.
This addresses the usage of `operator&` in `<list>`.
(Note there are still more headers with the same issue.)
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D112654
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
Fixes the tests added in D110852 for the debug iterators.
Similar issues with hijacking `operator&` still exist, they will be
addressed separately.
Reviewed By: #libc, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D111564
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
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
Add this attribute to some types to ensure that they have
debug info.
The debug info for these classes are required for debuggers to display
some STL types. With constructor homing (a new debug info optimization)
their debug info isn't emitted because their constructors are never
called.
The list of types with the attribute added are __hash_value_type,
__value_type, __tree_node_base, __tree_node, __hash_node, __list_node,
and __forward_list_node.
Differential Revision: https://reviews.llvm.org/D98750
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.
Generally these calls aren't vulnerable to ADL because they involve only
primitive types. The ones in <list> and <vector> drag in namespace std
but that's OK; the ones in <fstream> and <strstream> are vulnerable
iff `CharT` is an enum type, which seems far-fetched.
But absolutely zero of them *need* ADL to happen; so in my opinion
they should all be consistently qualified, just like calls to any
other (non-user-customizable) functions in namespace std.
Also: Include <cstring> and <cwchar> in <__string>.
We seemed to be getting lucky that <memory> included <iterator>
included <iosfwd> included <wchar.h>. That gave us the
global-namespace `wmemmove`, but not `_VSTD::wmemmove`.
This is now fixed.
I didn't touch these headers:
<ext/__hash> uses strlen, safely
<support/ibm/locale_mgmt_aix.h> uses memcpy, safely
<string.h> uses memchr and strchr, safely
<wchar.h> uses wcschr, safely
<__bsd_locale_fallbacks.h> uses wcsnrtombs, safely
Differential Revision: https://reviews.llvm.org/D93061
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
The debug mode always had three possibilities:
- _LIBCPP_DEBUG is undefined => no assertions
- _LIBCPP_DEBUG == 0 => some assertions
- _LIBCPP_DEBUG == 1 => some assertions + iterator checks
This was documented that way, however the code did not make this clear
at all. The discrepancy between _LIBCPP_DEBUG and _LIBCPP_DEBUG_LEVEL
was especially confusing. I reworked how the various macros are defined
without changing anything else to make the code clearer.
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.
Nikolas Klauser