This is a fairly mechanical change, it just moves each algorithm into
its own header. This is intended to be a NFC.
This commit re-applies 7ed7d4ccb8, which was reverted in 692d7166f7
because the Modules build got broken. The modules build has now been
fixed, so we're re-committing this.
Differential Revision: https://reviews.llvm.org/D103583
Attribution note
----------------
I'm only committing this. This commit is a mix of D103583, D103330 and
D104171 authored by:
Co-authored-by: Christopher Di Bella <cjdb@google.com>
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
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
When we removed the allocator<void> specialization, the triviality of
std::allocator<void> changed because the primary template had a
non-trivial default constructor and the specialization didn't
(so std::allocator<void> went from trivial to non-trivial).
This commit fixes that oversight by giving a trivial constructor to
the primary template when instantiated on cv-void.
This was reported in https://llvm.org/PR50299.
Differential Revision: https://reviews.llvm.org/D104398
A few slipped through the cracks because D104175 and D104170 didn't
concern themselves with newer commits.
Differential Revision: https://reviews.llvm.org/D104414
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
Also, fix the last issue that prevented GCC 11 from passing the test
suite. Thanks to everyone else who fixed issues.
Differential Revision: https://reviews.llvm.org/D104315
This has been broken out of D104170 since it should be merged whether or
not we go ahead with the module map changes.
Differential Revision: https://reviews.llvm.org/D104175
https://eel.is/c++draft/atomics.types.operations#23 says: ... the value of failure is order except that a value of `memory_order::acq_rel` shall be replaced by the value `memory_order::acquire` and a value of `memory_order::release` shall be replaced by the value `memory_order::relaxed`.
This failure mapping is only handled for `_LIBCPP_HAS_GCC_ATOMIC_IMP`. We are seeing bad code generation for `compare_exchange_strong(cmp, 1, std::memory_order_acq_rel)` when using libc++ in place of libstdc++: https://godbolt.org/z/v3onrrq4G.
This was caught by tsan tests after D99434, `[TSAN] Honor failure memory orders in AtomicCAS`, but appears to be an issue in non-tsan code.
Reviewed By: ldionne, dvyukov
Differential Revision: https://reviews.llvm.org/D103846
The runtimes build has assertions enabled, which is necessary to catch
some of the modules-related issues we've been seeing recently. This
patch enables testing with modules in the runtimes build so as to cover
those cases.
In the future, a better solution would be to systematically use versions
of Clang that have assertions enabled. However, the Clangs we release
currently don't have assertions enabled by default, which causes a
challenge for the CI (we could try to build our own Clang from ToT with
assertions in the CI, but that poses some problems).
Differential Revision: https://reviews.llvm.org/D104252
This started as an attempt to fix a GCC 11 warning of misplaced parentheses.
I then noticed that trying to fix the parentheses warning actually triggered
errors in the tests, showing that we were incorrectly assuming that the
implementation of ranges::advance was using operator+= or operator-=.
This commit fixes that issue and makes the tests easier to follow by
localizing the assertions it makes.
Differential Revision: https://reviews.llvm.org/D103272
The synchronization library was marked as disabled on Apple platforms
up to now because we were not 100% sure that it was going to be ABI
stable. However, it's been some time since we shipped it in upstream
libc++ now and there's been no changes so far. This patch enables the
synchronization library on Apple platforms, and hence commits the ABI
stability as far as that vendor is concerned.
Differential Revision: https://reviews.llvm.org/D96790
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
The buffer size (`__nbuf`) in `num_put::do_put` is currently not an
integral/core constant expression. As a result, `__nar` is a Variable Length
Array (VLA). VLAs are a GNU extension and not part of the base C++ standard, so
unless there is good reason to do so they probably shouldn't be used in any of
the standard library headers. The call to `__iob.flags()` is the only thing
keeping `__nbuf` from being a compile time constant, so the solution here is to
simply err on the side of caution and always allocate a buffer large enough to
fit the base prefix.
Note that, while the base prefix for hex (`0x`) is slightly longer than the
base prefix for octal (`0`), this isn't a concern. The difference in the space
needed for the value portion of the string is enough to make up for this.
(Unless we're working with small, oddly sized types such as a hypothetical
`uint9_t`, the space needed for the value portion in octal is at least 1 more
than the space needed for the value portion in hex).
This PR also adds `constexpr` to `__nbuf` to enforce compile time const-ness
going forward.
Reviewed By: Mordante, #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D103558
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.
Several macros were guarded with a check along the lines of:
#ifndef MACRO
# define MACRO ...
#endif
However, some of these macros are never intended to be defined by users,
so it's pointless to make this check (i.e. the first #ifndef is always
true). This commit removes those checks.
The motivation for doing this cleanup is to remove the impression that
arbitrary configurations macros can be defined by users when including
libc++ headers, which doesn't work reliably and leads to macro spaghetti.
If one needs to be able to override a knob in the __config, that's fine,
but the proper way to do that is to document the macro as being a public
facing knob in the documentation, and most likely to migrate that macro
to __config_site (depending on the nature of the macro).
Differential Revision: https://reviews.llvm.org/D103705
The "root nodes" of the graph are displayed in bold. My intent here
was to bold just the public-API headers, e.g. <vector> and
<experimental/coroutine> and <stdlib.h>, but not helper headers
such as <__functional_base> and <__iterator/next.h>. However,
the recent mass helper-header-ification has exposed defects in
this logic: all the new helpers were ending up bolded! Fix this.
Also, add <__undef_macros> to the list of headers we don't display
by default (like <__config>); it's not interesting to see those edges.
Also, add a sample `dot` command line to the `--help` text.
The `operator[]` of `_UnaryOp` and `_BinaryOp` returns the result of
calling `__op_`, so its return type should be `__result_type`, not
e.g. `_A0::value_type`. However, `_UnaryOp::value_type` also should
never have been `_A0::value_type`; it needs to be the correct type
for the result of the unary op, e.g. `bool` when the op is `logical_not`.
This turns out to matter when multiple operators are nested, e.g.
`+(v == v)` needs to have a `value_type` of `bool`, not `int`,
even when `v` is of type `valarray<int>`.
Differential Revision: https://reviews.llvm.org/D103416
This is a fairly mechanical change, it just moves each algorithm into its own header. This is a NFC.
Note: during this change, I burned down all the includes, so this follows "include only and exactly what you use."
Differential Revision: https://reviews.llvm.org/D103583
As discussed on cfe-dev [1], use the using_if_exists Clang attribute when
the compiler supports it. This makes it easier to port libc++ on top of
new platforms that don't fully support the C Standard library.
Previously, libc++ would fail to build when trying to import a missing
declaration in a <cXXXX> header. With the attribute, the declaration will
simply not be imported into namespace std, and hence it won't be available
for libc++ to use. In many cases, the declarations were *not* actually
required for libc++ to work (they were only surfaced for users to use
them as std::XXXX), so not importing them into namespace std is acceptable.
The same thing could be achieved by conscious usage of `#ifdef` along
with platform detection, however that quickly creates a maintenance
problem as libc++ is ported to new platforms. Furthermore, this problem
is exacerbated when mixed with vendor internal-only platforms, which can
lead to difficulties maintaining a downstream fork of the library.
For the time being, we only use the using_if_exists attribute when it
is supported. At some point in the future, we will start removing #ifdef
paths that are unnecessary when the attribute is supported, and folks
who need those #ifdef paths will be required to use a compiler that
supports the attribute.
[1]: http://lists.llvm.org/pipermail/cfe-dev/2020-June/066038.html
Differential Revision: https://reviews.llvm.org/D90257
If building code like this:
unsigned long val = 1000;
snprintf(buf, sizeof(buf), "%+lu", val);
with clang, clang warns
warning: flag '+' results in undefined behavior with 'u' conversion specifier [-Wformat]
Therefore, don't construct such undefined format strings. (There's
no compiler warnings here, as the compiler can't inspect dynamically
assembled format strings.)
This fixes number formatting in mingw-w64 if built with
`__USE_MINGW_ANSI_STDIO` defined (there, the '+' flag causes a
leading plus to be printed when formatting unsigned numbers too,
while the '+' flag doesn't cause any extra leading plus in other
stdio implementations).
Differential Revision: https://reviews.llvm.org/D103444
Raul Tambre