Commit Graph

3807 Commits

Author SHA1 Message Date
Mark de Wever 11e4001ba2 [libc++][format][nfc] Header cleanup.
Remove the unneeded macro protection, forward declarations, and
includes.

Reviewed By: #libc, Quuxplusone, ldionne, philnik

Differential Revision: https://reviews.llvm.org/D118925
2022-02-09 17:12:04 +01:00
Nikolas Klauser a5b4479d3c [libc++] Add papers from February 2022 plenary meeting
Reviewed By: ldionne, Quuxplusone, #libc

Spies: arichardson, libcxx-commits

Differential Revision: https://reviews.llvm.org/D119189
2022-02-09 10:21:19 +01:00
Joe Loser d7095e8035
[libc++] Remove outdated synopsis parts in experimental/functional
Remove mentions of `experimental::function`, its operators, etc. They are no
longer in `experimental/functional`.

Differential Revision: https://reviews.llvm.org/D119204
2022-02-08 19:06:35 -05:00
Louis Dionne 817d897b57 [libc++] Remove _LIBCPP_ABI_UNSTABLE
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
2022-02-08 15:18:09 -05:00
Louis Dionne 506cf6dc04 [libc++] Fix modules and benchmarks CI builds when incomplete features are disabled
Differential Revision: https://reviews.llvm.org/D119036
2022-02-08 15:15:07 -05:00
Joe Loser 66dea85b36
[libc++] Mark some members private in experimental/functional
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
2022-02-07 18:06:56 -05:00
Louis Dionne 157bbe6aea [libc++] Remove the ability to use the std::nullptr_t emulation in C++03 mode
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
2022-02-07 17:51:05 -05:00
Nikolas Klauser 24c12bfb33 [libc++] __config cleanup; _LIBCPP_ABI_UNSTABLE should set _LIBCPP_ABI_VERSION
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
2022-02-05 12:00:54 +01:00
Arthur O'Dwyer ea2206d70d [libc++] Replace includes of <utility> with specific detail headers
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
2022-02-04 17:08:32 -05:00
Arthur O'Dwyer cc1d02ba2d [libc++] No longer support ranges::begin(x) when x is an array of incomplete type.
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
2022-02-04 16:11:39 -05:00
Nikolas Klauser 679f8a885b [libc++] Move fpos into its own header
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
2022-02-04 21:53:43 +01:00
Louis Dionne abcbe87311 [libc++] Remove unused code paths for non-existent builtins
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
2022-02-04 15:51:42 -05:00
Arthur O'Dwyer 44cdca37c0 [libc++] Define `namespace views` in its own detail header.
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
2022-02-04 12:37:47 -05:00
Arthur O'Dwyer fa6b9e4010 [libc++] Normalize all our '#pragma GCC system_header', and regression-test.
Now we'll notice if a header forgets to include this magic phrase.

Differential Revision: https://reviews.llvm.org/D118800
2022-02-04 12:27:19 -05:00
Nikolas Klauser b82da8b555 [libc++] Remove vector base class
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
2022-02-04 13:06:28 +01:00
Tiago Macarios eaadc45156 [libc++] Fix chrono::duration constructor constraint
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
2022-02-03 18:07:12 -05:00
Nikolas Klauser 5173f43cc8 [libc++] Remove the std::string base class
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
2022-02-03 22:57:23 +01:00
Konstantin Varlamov 823fa098aa [libc++][ranges][NFC] Test the specializations of `tuple_{size,element}` for ranges.
Also update the synopsis in `<ranges>` to mention the specializations.

Differential Revision: https://reviews.llvm.org/D118686
2022-02-02 22:58:33 -08:00
Nikolas Klauser 610979b301 [libc++][ranges] Add ranges::in_out_out_result
Add `ranges::in_out_out_result`

Reviewed By: Quuxplusone, Mordante, #libc

Spies: libcxx-commits, mgorny

Differential Revision: https://reviews.llvm.org/D118634
2022-02-03 02:17:48 +01:00
Konstantin Varlamov e65d3760a3 [libc++][ranges] Implement `indirectly_copyable{,_storable}`.
Also refactor tests for `indirectly_movable{,_storable}`.

Differential Revision: https://reviews.llvm.org/D118432
2022-02-02 13:27:44 -08:00
Konstantin Varlamov f681d7d558 [libc++][ranges][NFC] Add contiguous_iterator_tag to the <iterator> synopsis
It was previously implemented by commit [45d048c20](https://reviews.llvm.org/rG45d048c20440989df2b4e1be1f9343225e7741ab).

Reviewed By: #libc, Quuxplusone, philnik, ldionne

Differential Revision: https://reviews.llvm.org/D118751
2022-02-02 12:53:15 -08:00
Arthur O'Dwyer 0b5fb7c604 [libc++] [NFC] s/__referenceable/__can_reference/
The Standard name for this exposition-only concept is _can-reference_.

Differential Revision: https://reviews.llvm.org/D118726
2022-02-02 13:40:21 -05:00
Arthur O'Dwyer b2a0cc1c65 [libc++] Guard bits of 598983d7 against _LIBCPP_HAS_NO_CONCEPTS. 2022-02-02 11:19:46 -05:00
Arthur O'Dwyer 93e7f35ac3 [libc++] [NFC] Normalize some `#ifndef _LIBCPP_HAS_NO_CONCEPTS`. 2022-02-02 11:02:56 -05:00
Arthur O'Dwyer 38db42d004 [libc++] [NFC] s/_LIBCPP_STD_VER > 17 && !defined(_LIBCPP_HAS_NO_CONCEPTS)/!defined(_LIBCPP_HAS_NO_CONCEPTS)/
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
2022-02-02 11:02:56 -05:00
Nikolas Klauser 598983d7a9 [libc++][P2321R2] Add specializations of basic_common_reference and common_type for pair
Add specializations of basic_common_reference and common_type for pair

Reviewed By: Quuxplusone, Mordante, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D117506
2022-02-02 10:47:04 +01:00
Tom Stellard a2601c9887 Bump the trunk major version to 15 2022-02-01 23:54:52 -08:00
Nikolas Klauser 453620f55e [libc++] Make _VSTD and alias for std
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
2022-02-01 22:41:51 +01:00
Mark de Wever d7c4072fdb [libc++] Remove unneeded qualifier.
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
2022-02-01 16:33:03 -05:00
Arthur O'Dwyer 6a56d5cc25 [libc++] Fix LWG3589 "The const lvalue reference overload of get for subrange..."
https://cplusplus.github.io/LWG/issue3589

Differential Revision: https://reviews.llvm.org/D117961
2022-02-01 15:14:44 -05:00
Nikolas Klauser 9c52a19e32 [libc++][NFC] Add namespace comments in ranges
With this patch there should be no more namespaces without closing comment

Reviewed By: ldionne, Quuxplusone, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D118668
2022-02-01 18:18:13 +01:00
Martin Storsjö eb9645819c [libcxx] [Windows] Pick a unique bit for __regex_word
The old `__regex_word` aliased the mask for `xdigit`, causing stray
test failures.

The diff may look surprising, as if the previous faulty value had
been set specifically for Windows - but this is due to a restructuring
in 411c630bae. Prior to that, there
were OS specific settings for some OSes, and one fallback used for
the rest (which turns out to not work for Windows).

Differential Revision: https://reviews.llvm.org/D118188
2022-01-31 23:13:58 +02:00
Arthur O'Dwyer bf150e8dab [libc++] [ranges] ADL-proof ranges::iter_{swap,move}.
As discovered in D117817, `std::ranges::input_range<Holder<Incomplete>*[10]>`
hard-errored before this patch. That's because `input_range` requires
`iter_rvalue_reference_t`, which requires `iter_move`, which was
not ADL-proofed.

Add ADL-proofing tests to all the range refinements.
`output_range` and `common_range` shouldn't be affected,
and all the others subsume `input_range` anyway, but we might as
well be thorough.

Differential Revision: https://reviews.llvm.org/D118213
2022-01-31 14:14:26 -05:00
Arthur O'Dwyer c965d5448e [libc++] [ranges] Implement std::ranges::distance
This includes an experimental workaround for
LWG3664 "LWG3392 broke std::ranges::distance(a, a+3)",
but the workaround may be incomplete, I'm not sure.
This should be re-audited when LWG3664 is actually adopted,
to see if we need to change anything about our implementation.

See also https://github.com/microsoft/STL/pull/2500

Differential Revision: https://reviews.llvm.org/D117940
2022-01-31 12:23:10 -05:00
Arthur O'Dwyer 23f73ff5f6 [libc++] [NFC] Audit LWG issues for "Nothing To Do" and "Complete".
Each "Nothing To Do" issue only changed nits in the English wording,
not anything to do with the code.
Each "Complete" issue was completed already, as far as I can tell.
I tried to err on the side of caution: I didn't mark a few issues
whose P/Rs were very invasive and would take time to verify, and I
didn't mark a lot of issues involving features we haven't even started
yet.

Differential Revision: https://reviews.llvm.org/D117960
2022-01-31 12:10:22 -05:00
Arthur O'Dwyer 2eb2ff2a02 [libc++] Merge _LIBCPP_HAS_NO_RANGES into _LIBCPP_HAS_NO_CONCEPTS. NFC.
The macro that opts out of `std::ranges::` functionality is called
`_LIBCPP_HAS_NO_INCOMPLETE_RANGES`, and is unrelated to this macro
which is specifically about _compiler_ support for the _syntax_.

The only non-mechanical diff here is in `<__config>`.

Differential Revision: https://reviews.llvm.org/D118507
2022-01-31 12:10:22 -05:00
Nikolas Klauser f3514af492 [libc++][ranges] Add ranges::in_in_out_result
Add `ranges::in_in_out_result`

Reviewed By: Quuxplusone, Mordante, #libc

Spies: CaseyCarter, libcxx-commits, mgorny

Differential Revision: https://reviews.llvm.org/D117512
2022-01-31 16:33:45 +01:00
Arthur O'Dwyer d1c4c75531 [libc++] Fix the last instances of `namespace ranges::inline...`. NFC.
Make these look the same as everywhere else.
2022-01-29 11:10:04 -05:00
Martin Storsjö de5d38ef2d [libcxx] Allow using thread safety annotations in MinGW mode
These were omitted in all Windows configurations, but it turns out
that they work just fine in MinGW mode.

This allows converting a couple cases of "XFAIL: LIBCXX-WINDOWS-FIXME"
into "XFAIL: msvc" as the bug is specific to MSVC mode (clang-cl).

Differential Revision: https://reviews.llvm.org/D118192
2022-01-28 11:20:58 +02:00
Arthur O'Dwyer bf20a09790 [libc++] [P1614] Implement the second half of [cmp.alg]: compare_{strong,weak,partial}_fallback.
The tests for these are just copy-pasted from the tests for std::{strong,weak,partial}_order,
and then I added an extra clause in each (test_2()) to test the stuff that's not just the same
as std::*_order.

This also includes the fix for https://wg21.link/LWG3465 (which falls naturally out of the
"you must write it three times" style, but I've added test cases for it also).

There is an action item here to go back and give good diagnostics for SFINAE failures
in these CPOs. I've filed this as https://github.com/llvm/llvm-project/issues/53456 .

Differential Revision: https://reviews.llvm.org/D111514
2022-01-27 17:48:01 -05:00
Brian Cain d5ab243c6f Omit atomic_{,un}signed_lock_free if unsupported
On targets that have limited atomic support, e.g. ones that define
ATOMIC_*_LOCK_FREE to '1' ("sometimes lock free"), we would end up
referencing yet-undefined __libcpp_{,un}signed_lock_free.

This commit adds a guard to prevent these references for such
targets.

Differential Revision: https://reviews.llvm.org/D118391
2022-01-27 14:29:08 -08:00
Arthur O'Dwyer 9021f3682c [libc++] [ranges] ref_view and empty_view are borrowed ranges. Normalize borrowed_range tests.
Differential Revision: https://reviews.llvm.org/D118164
2022-01-27 14:21:51 -05:00
Arthur O'Dwyer 8c98ce4dfa [libc++] Fix a typo in reverse_iterator::operator=.
We should be checking `is_assignable<It&, ...>`.
`is_assignable<It, ...>` checks for an rvalue left-hand side, which
is basically never assignable-to.
Found while looking into https://cplusplus.github.io/LWG/issue3435 .

Differential Revision: https://reviews.llvm.org/D117660
2022-01-27 14:21:50 -05:00
Louis Dionne d27cbfa9d3 [libc++] Fix bug in ranges::advance
In `ranges::advance(iter, n, bound)`, we'd incorrectly handle the case
where bound < iter and n is 0:

    int a[10];
    int *p = a+5;
    int *bound = a+3;
    std::ranges::advance(p, 0, bound);
    assert(p - a == 5); // we'd return 3 before this patch

This was caused by an incorrect handling of 0 inside __magnitude_geq.

Differential Revision: https://reviews.llvm.org/D117240
2022-01-27 10:57:54 -05:00
Louis Dionne 0902eb30ad [libc++] Fix common_iterator for output_iterators
We were missing a constraint in common_iterator's iterator_traits and
we were eagerly instantiating iter_value_t even when invalid.

Thanks to Casey Carter for finding this bug.

Differential Revision: https://reviews.llvm.org/D117449
2022-01-27 10:57:04 -05:00
Arthur O'Dwyer 7ea4fe7ede [libc++] Fix LWG3390: move_iterator now handles move-only iterators.
This can't really be tested until C++20 move_iterator is completely implemented.

Differential Revision: https://reviews.llvm.org/D117327
2022-01-26 23:50:26 -05:00
Arthur O'Dwyer 4b3e0d2a7e [libc++] Fix LWG3533 "Make `base() const&` consistent..."
Fixed in counted_iterator and transform_view::iterator.
The LWG issue also affected elements_view::iterator, but we haven't
implemented that one yet, and whoever does implement it will get
the fix for free if they just follow the working draft's wording.

Drive-by stop calling `.base()` on test iterators in the test,
and improve the transform_view::iterator/sentinel tests.

Differential Revision: https://reviews.llvm.org/D117329
2022-01-26 19:38:39 -05:00
Arthur O'Dwyer c99a585399 [libc++] Make C++03 reference_wrapper more like C++11.
Remove a bunch of LIBCPP_CXX03_LANG. This is the result of a
rabbithole to re-eliminate the workaround I introduced into
std::cref in D117953. It turns out that Clang's C++03 mode
(the only compiler we care about C++03 for) now supports all
the things we were originally eschewing via LIBCPP_CXX03_LANG;
we can fully support these reference_wrapper features in
C++03 mode, and un-XFAIL the relevant tests.

Drive-by constexprify a few more tests.

Differential Revision: https://reviews.llvm.org/D117974
2022-01-26 19:34:03 -05:00
Arthur O'Dwyer 16031cbf2b [libc++] Fix LWG3557 "static_cast expression in convertible_to has the wrong operand"
https://cplusplus.github.io/LWG/issue3557
I think the code change is unobservable, so we could just close this as
"Nothing To Do" instead; but it seems appropriate to follow the Standard's
wording here as closely as possible.

Differential Revision: https://reviews.llvm.org/D117964
2022-01-26 19:32:46 -05:00
Arthur O'Dwyer ff84c635b7 [libc++] [ranges] Fix LWG3470 "convertible-to-non-slicing seems to reject valid case"
Differential Revision: https://reviews.llvm.org/D117941
2022-01-26 19:30:12 -05:00