`<filesystem>` header has been around for a while now, so we can safely remove
`<experimental/filesystem>` header. `_LIBCPP_DEPRECATED_EXPERIMENTAL_FILESYSTEM`
suggests we were going to remove `<experimental/filesystem>` in llvm 11 release,
but we never did. So, remove the experimental header now, its associated tests,
and the `_LIBCPP_DEPRECATED_EXPERIMENTAL_FILESYSTEM` macro.
Differential Revision: https://reviews.llvm.org/D119603
Despite the comment saying `[[no_unique_address]]` on the `__base_` data member
makes clang crash, this does not seem to be true on CI. So, mark `__base_` with
`_LIBCPP_NO_UNIQUE_ADDRESS`.
Differential Revision: https://reviews.llvm.org/D119208
- add some test cases for `cbegin`/`cend`;
- make class definitions generally follow the order in which they are
used;
- add a missing include.
Reviewed By: philnik
Differential Revision: https://reviews.llvm.org/D119214
This reverts commit 2722ac65. As explained in D115906, this was actually
unnecessary and it broke the external threading configuration.
Differential Revision: https://reviews.llvm.org/D119484
`ranges_swap_ranges.h` includes `<type_traits>` but does not use anything from
it. So, remove the include.
Differential Revision: https://reviews.llvm.org/D119491
`{back,front}_insert_iterator` and `ostream{,buf}_iterator` effectively
fully implement the One Ranges Proposal already, so mark them as done:
- the change to `difference_type` was made by D103273;
- default constructors and the associated default member initializers
were removed by wg21.link/P2325 (implemented by D102468).
Also fix a stale template signature in the `<iterator>` synopsis.
In libc++, checking specific `_LIBCPP_DEBUG_LEVEL` levels is used everywhere except in `comp_ref_type.h`. `_LIBCPP_DEBUG` is meant as a user-facing option, and internally libc++ should be checking the value of `_LIBCPP_DEBUG_LEVEL`.
The definition of `std::__debug_less` doesn't need to be hidden behind the macro, we can unconditionally expose it. It will be unused by `__comp_ref_type` unless debug mode is enabled.
This was suggested in D118940.
Reviewed By: #libc, philnik, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D118950
b07b5bd727 adds a use of `__comp_ref_type.h` to `std::min`. When libc++ is built with `-D_LIBCPP_DEBUG=0`, this enables `std::__debug_less`, which is only marked constexpr after c++17.
`std::min` itself is marked as being `constexpr` as of c++14, so by extension, `std::__debug_less` should also be marked `constexpr` for the same versions so that `std::min` can use it. This change lowers the guard from `> 17` to `> 11`.
Reproducer in godbolt: https://godbolt.org/z/ans3TGsj8
```
constexpr int x() { return std::min<int>({1, 2, 3, 4}); }
static_assert(x() == 1);
```
Reviewed By: #libc, philnik, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D118940
Remove mentions of `experimental::function`, its operators, etc. They are no
longer in `experimental/functional`.
Differential Revision: https://reviews.llvm.org/D119204
Previously, _LIBCPP_ABI_UNSTABLE would be used interchangeably with
_LIBCPP_ABI_VERSION >= 2. This was confusing and creating unnecessary
complexity.
This patch removes _LIBCPP_ABI_UNSTABLE -- instead, the LIBCXX_ABI_UNSTABLE
CMake option will result in the LIBCXX_ABI_VERSION being set to '2', the
current unstable ABI. As a result, in the code, we only have _LIBCPP_ABI_VERSION
to check in order to query the current ABI version.
As a fly-by, this also defines the ABI namespace during CMake configuration
to reduce complexity in __config. I believe it was previously done this
way because we used to try to use __config_site as seldom as possible.
Now that we always ship a __config_site, it doesn't really matter and
I think being explicit about how the library is configured in the __config_site
is actually a feature.
Differential Revision: https://reviews.llvm.org/D119173
Some members are public but should be private. Nothing requires they are public
right now, so make them private.
Differential Revision: https://reviews.llvm.org/D119097
Back in https://reviews.llvm.org/D109459, we stopped using the C++03
emulation for std::nullptr_t by default, which was an ABI break. We
still left a knob for users to turn it back on if they were broken by
the change, with a note that we would remove that knob after one release.
The time has now come to remove the knob and clean up the std::nullptr_t
emulation.
Differential Revision: https://reviews.llvm.org/D114786
Some `__config` cleanup and `_LIBCPP_ABI_UNSTABLE` should set `_LIBCPP_ABI_VERSION`, since the latest ABI version //is// the unstable ABI.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D118989
Basically a rebase of D104980; most of that patch had already happened
via gradual drive-by changes, but this finishes it up.
Don't touch the inclusions from `<__functional_base>`, `<__hash_table>`,
or `<__locale>`; those could be removed if we propagated the
inclusions up to the includers of those files, but there are lots
of those includers.
`<algorithm>`, `<functional>`, and `<memory>` already include `<utility>`
at the top level. `<iterator>` did not, so I've added it there.
Differential Revision: https://reviews.llvm.org/D119020
var-const points out that `ranges::begin` is (non-normatively
but explicitly) always supposed to return a `std::input_or_output_iterator`,
and `Incomplete*` is not a `std::input_or_output_iterator` because it
has no `operator++`. Therefore, we should never return `Incomplete*`
from `ranges::begin(x)`, even when `x` is `Incomplete(&)[]`. Instead,
just SFINAE away.
Differential Revision: https://reviews.llvm.org/D118963
For some reason `<string>` defines `std::fpos`, which should be defined in `<ios>`.
Reviewed By: Quuxplusone, Mordante, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D118914
It looks like we added some checks to try and use builtin type traits
in https://reviews.llvm.org/D67900, but some of those type traits are
never implemented as builtins, so this is essentially dead code.
Fixes llvm-project#53569
Differential Revision: https://reviews.llvm.org/D118923
Discovered in the comments on D118748: we would like this namespace
to exist anytime Ranges exists, regardless of whether concepts syntax
is supported. Also, we'd like to fully granularize the <ranges> header,
which means not putting any loose declarations at the top level.
Differential Revision: https://reviews.llvm.org/D118809
Remove the vector base class as suggested by @ldionne
Reviewed By: ldionne, Quuxplusone, #libc
Spies: libcxx-commits, ldionne
Differential Revision: https://reviews.llvm.org/D117108
As per [time.duration.cons]/1, the constructor constraint should be on
const Rep2&. As it is now the code will fail to compile in certain
cases, for example (https://godbolt.org/z/c7fPrcTYM):
struct S{
operator int() const&& noexcept = delete;
operator int() const& noexcept;
};
const S &fun();
auto k = std::chrono::microseconds{fun()};
Differential Revision: https://reviews.llvm.org/D118902
Removing the base class of std::basic_string is not an ABI break, so we can remove any references to it from the header.
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D118733
Per Discord discussion, we're normalizing on a simple `!defined(_LIBCPP_HAS_NO_CONCEPTS)`
so that we can do a big search-and-replace for `!defined(_LIBCPP_HAS_NO_CONCEPTS)`
back into `_LIBCPP_STD_VER > 17` when we're ready to abandon support for concept-syntax-less
compilers.
Differential Revision: https://reviews.llvm.org/D118748
There is no practical difference between `_VSTD` and `std` so we should just remove `_VSTD`. This is the first step.
Reviewed By: ldionne, #libc
Spies: jeroen.dobbelaere, wmaxey, EricWF, lebedev.ri, __simt__, dim, mgrang, sstefan1, wenlei, smeenai, libcxx-commits, #libc_vendors
Differential Revision: https://reviews.llvm.org/D117811
In D117811 @Quuxplusone pointed out the friend declarations don't need
to be qualified. Removing the qualification should avoid needing to add
a GCC work-around when changing _VSTD to std.
Reviewed By: Quuxplusone, philnik, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D118719
Joe Loser