History log of /llvm-project-15.0.7/libcxx/include/span (Results 1 – 25 of 61)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3
# d761fe6e 11-Aug-2022 Louis Dionne <[email protected]>

[libc++] Add a missing assertion in std::span's constructor

Also, add missing tests for assertions in span constructors. Now I
believe that all of std::span's API should be hardened, and all the
ass

[libc++] Add a missing assertion in std::span's constructor

Also, add missing tests for assertions in span constructors. Now I
believe that all of std::span's API should be hardened, and all the
assertions should have a corresponding test.

Differential Revision: https://reviews.llvm.org/D131681

(cherry picked from commit 8c6319e30a357fb9b25db09b6f5fc9cf3e7c4aab)

show more ...


Revision tags: llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# de4a57cb 27-Jun-2022 Louis Dionne <[email protected]>

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604,
and 489637e66dd3. 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

show more ...


Revision tags: llvmorg-14.0.6, llvmorg-14.0.5
# 633d1d0d 06-Jun-2022 Louis Dionne <[email protected]>

[libc++] Use bounded iterators in std::span when the debug mode is enabled

Previously, we'd use raw pointers when the debug mode was enabled,
which means we wouldn't get out-of-range checking with s

[libc++] Use bounded iterators in std::span when the debug mode is enabled

Previously, we'd use raw pointers when the debug mode was enabled,
which means we wouldn't get out-of-range checking with std::span's
iterators.

This patch introduces a new class called __bounded_iter which can
be used to wrap iterators and make them carry around bounds-related
information. This allows iterators to assert when they are dereferenced
outside of their bounds.

As a fly-by change, this commit removes the _LIBCPP_ABI_SPAN_POINTER_ITERATORS
knob. Indeed, not using a raw pointer as the iterator type is useful to
avoid users depending on properties of raw pointers in their code.

This is an alternative to D127401.

Differential Revision: https://reviews.llvm.org/D127418

show more ...


# db1978b6 16-Jun-2022 Nikolas Klauser <[email protected]>

[libc++] Mark standard-mandated includes as such

Reviewed By: ldionne, Mordante, #libc, saugustine

Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman

Differential

[libc++] Mark standard-mandated includes as such

Reviewed By: ldionne, Mordante, #libc, saugustine

Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman

Differential Revision: https://reviews.llvm.org/D127953

show more ...


# 4cd04d16 13-Jun-2022 Mark de Wever <[email protected]>

[libc++] Removes unneeded <iterator> includes.

Reviewed By: #libc, philnik

Differential Revision: https://reviews.llvm.org/D127675


# cb48ed38 15-Jun-2022 Joe Loser <[email protected]>

[libc++][NFCI] span: replace enable_if with concepts

Several span constructors use `enable_if` which is verbose. Replace these with
concepts or requires expressions.


# 3cd4531b 10-Jun-2022 Nikolas Klauser <[email protected]>

[libc++] Granularize <iterator> includes

Reviewed By: ldionne, #libc

Spies: libcxx-commits, wenlei

Differential Revision: https://reviews.llvm.org/D127445


Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# f3966eaf 01-Apr-2022 Louis Dionne <[email protected]>

[libc++] Make the Debug mode a configuration-time only option

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 witho

[libc++] Make the Debug mode a configuration-time only option

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

show more ...


# 4eab04f8 03-Jun-2022 Louis Dionne <[email protected]>

[libc++] Remove a bunch of conditionals on _LIBCPP_DEBUG_LEVEL

Instead of providing two different constructors for iterators that
support the debug mode, provide a single constructor but leave the
c

[libc++] Remove a bunch of conditionals on _LIBCPP_DEBUG_LEVEL

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

show more ...


# 643df8fa 10-May-2022 Louis Dionne <[email protected]>

[libc++] Make sure that all headers can be included with modules enabled

This commit ensures that we can include all libc++ headers with modules
enabled. It adds a test to ensure that this doesn't r

[libc++] Make sure that all headers can be included with modules enabled

This commit ensures that we can include all libc++ headers with modules
enabled. It adds a test to ensure that this doesn't regress, which is
necessary because our modules CI job does not build in all Standard modes.

Differential Revision: https://reviews.llvm.org/D125331

show more ...


# 9924d8d6 06-May-2022 Konstantin Varlamov <[email protected]>

[libc++][ranges] Implement `views::take`.

The view itself has been implemented previously -- this patch only adds
the ability to pipe it.

Also implements [P1739](https://wg21.link/p1739) (partially

[libc++][ranges] Implement `views::take`.

The view itself has been implemented previously -- this patch only adds
the ability to pipe it.

Also implements [P1739](https://wg21.link/p1739) (partially) and [LWG3407](https://wg21.link/lwg3407).

Differential Revision: https://reviews.llvm.org/D123600

show more ...


# 385cc25a 25-Mar-2022 Louis Dionne <[email protected]>

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any publ

[libc++] Ensure that all public C++ headers include <__assert>

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

show more ...


# 6a7f0551 21-Mar-2022 Louis Dionne <[email protected]>

[libc++] Re-enable workaround for pre-ranges CTAD in std::span

See https://reviews.llvm.org/D121626 for details -- this re-enables the
CTAD we removed, since it does break some stuff as well (even t

[libc++] Re-enable workaround for pre-ranges CTAD in std::span

See https://reviews.llvm.org/D121626 for details -- this re-enables the
CTAD we removed, since it does break some stuff as well (even though it's
not nearly as bad as the removed constructors fixed by D121626).

Differential Revision: https://reviews.llvm.org/D122184

show more ...


# d4c39f1a 14-Mar-2022 Louis Dionne <[email protected]>

[libc++] Add workaround to avoid breaking users of <span> when <ranges> are disabled

Back in 3a208c68942e, we implemented the range-based constructor for <span>.
However, in doing so, we removed a p

[libc++] Add workaround to avoid breaking users of <span> when <ranges> are disabled

Back in 3a208c68942e, we implemented the range-based constructor for <span>.
However, in doing so, we removed a previous non-standard constructor that
we provided before shipping <ranges>. Unfortunately, that breaks code that
was relying on a range-based constructor until we ship all of <ranges>.

This patch reintroduces the old non-conforming constructors and tests
that were removed in 3a208c68942e and uses them whenever <ranges> is
not provided (e.g. in LLVM 14). This is only a temporary workaround
until we enable <ranges> by default in C++20, which should hopefully
happen by LLVM 15.

The goal is to cherry-pick this workaround back to the LLVM 14 release
branch, since I suspect the constructor removal may otherwise cause
breakage out there, like the breakage I saw internally.

We could have avoided this situation by waiting for C++20 to be finalized
before shipping std::span. For example, we could have guarded it with
something like _LIBCPP_HAS_NO_INCOMPLETE_RANGES to prevent users from
accidentally starting to depend on it before it is stable. We did not
have these mechanisms when std::span was first implemented, though.

Differential Revision: https://reviews.llvm.org/D121626

show more ...


# 849e749d 14-Mar-2022 Louis Dionne <[email protected]>

[libc++][NFC] Remove several redundant #if _LIBCPP_STD_VER > 17 in <span>

It turns out that the whole header is only enabled in C++20 and above,
so these checks were redundant (and always true).

Di

[libc++][NFC] Remove several redundant #if _LIBCPP_STD_VER > 17 in <span>

It turns out that the whole header is only enabled in C++20 and above,
so these checks were redundant (and always true).

Differential Revision: https://reviews.llvm.org/D121604

show more ...


Revision tags: llvmorg-14.0.0
# d2baefae 12-Mar-2022 Joe Loser <[email protected]>

[libc++] Replace _LIBCPP_HAS_NO_CONCEPTS with _LIBCPP_STD_VER > 17. NFCI.

All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBC

[libc++] Replace _LIBCPP_HAS_NO_CONCEPTS with _LIBCPP_STD_VER > 17. NFCI.

All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.

Differential Revision: https://reviews.llvm.org/D121528

show more ...


Revision tags: llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2
# f87aa19b 14-Feb-2022 Louis Dionne <[email protected]>

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

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

show more ...


Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init
# 53406fb6 01-Feb-2022 Arthur O'Dwyer <[email protected]>

[libc++] Guard much of std::ranges under _LIBCPP_HAS_NO_INCOMPLETE_RANGES.

The logic here is that we are disabling *only* things in `std::ranges::`.
Everything in `std::` is permitted, including `de

[libc++] Guard much of std::ranges under _LIBCPP_HAS_NO_INCOMPLETE_RANGES.

The logic here is that we are disabling *only* things in `std::ranges::`.
Everything in `std::` is permitted, including `default_sentinel`, `contiguous_iterator`,
`common_iterator`, `projected`, `swappable`, and so on. Then, we include
anything from `std::ranges::` that is required in order to make those things
work: `ranges::swap`, `ranges::swap_ranges`, `input_range`, `ranges::begin`,
`ranges::iter_move`, and so on. But then that's all. Everything else (including
notably all of the "views" and the `std::views` namespace itself) is still
locked up behind `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`.

Differential Revision: https://reviews.llvm.org/D118736

show more ...


# fa6b9e40 02-Feb-2022 Arthur O'Dwyer <[email protected]>

[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/D1188

[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

show more ...


# 2eb2ff2a 31-Jan-2022 Arthur O'Dwyer <[email protected]>

[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 thi

[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

show more ...


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# eb8650a7 17-Nov-2021 Louis Dionne <[email protected]>

[runtimes][NFC] Remove filenames at the top of the license notice

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 st

[runtimes][NFC] Remove filenames at the top of the license notice

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.

show more ...


# 0412c007 14-Oct-2021 Arthur O'Dwyer <[email protected]>

[libc++] Implement LWG3369, tweak CTAD for std::span.

The original bug doesn't reproduce on Clang, allegedly because of
https://bugs.llvm.org/show_bug.cgi?id=44484
We already test STL's exact test c

[libc++] Implement LWG3369, tweak CTAD for std::span.

The original bug doesn't reproduce on Clang, allegedly because of
https://bugs.llvm.org/show_bug.cgi?id=44484
We already test STL's exact test case, in "span.cons/deduct.pass.cpp",
which I'm touching just for the heck of it.

Differential Revision: https://reviews.llvm.org/D111838

show more ...


# 8e92410e 13-Oct-2021 Joe Loser <[email protected]>

[libc++][docs] Mark LWG3274 as complete

Mark LWG3274 as complete. The feature test macro `__cpp_lib_span` was added in
`6d2599e4f776d0cd88438cb82a00c4fc25cc3f67`.

https://wg21.link/p1024 mentions m

[libc++][docs] Mark LWG3274 as complete

Mark LWG3274 as complete. The feature test macro `__cpp_lib_span` was added in
`6d2599e4f776d0cd88438cb82a00c4fc25cc3f67`.

https://wg21.link/p1024 mentions marking `span:::empty()` with
`[[nodiscard]]` which is not done yet. So, do that and add tests.

Reviewed By: ldionne, Quuxplusone, Mordante, #libc

Differential Revision: https://reviews.llvm.org/D111516

show more ...


# 3a208c68 08-Oct-2021 Joe Loser <[email protected]>

[libc++] Implement P1394r4 for span: range constructor

Implement https://wg21.link/p1394 which allows span to be constructible
from any contiguous forwarding-range that has a compatible element type

[libc++] Implement P1394r4 for span: range constructor

Implement https://wg21.link/p1394 which allows span to be constructible
from any contiguous forwarding-range that has a compatible element type.

Fixes https://bugs.llvm.org/show_bug.cgi?id=51443

Reviewed By: ldionne, Quuxplusone, #libc

Differential Revision: https://reviews.llvm.org/D110503

show more ...


# 9451d9da 27-Sep-2021 Joe Loser <[email protected]>

[libc++][NFC] s/enable_if<...>::type/enable_if_t<...> in span

There is some use of `enable_if<...>::type` when the rest of the file
uses `enable_if_t`. So, use `enable_if_t` consistently throughout.


123