History log of /llvm-project/libcxx/include/span (Results 1 – 25 of 96)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7
# b9a2658a 21-Dec-2024 Nikolas Klauser <nikolasklauser@berlin.de>

[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)

This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-

[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)

This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the
RFC, we initially proposed selecting the right headers from the Clang
driver, however consensus seemed to steer towards handling this in the
library itself. This patch implements that direction.

At a high level, the changes basically amount to making each public
header look like this:

```
// inside <vector>
#ifdef _LIBCPP_CXX03_LANG
# include <__cxx03/vector>
#else
// normal <vector> content
#endif
```

In most cases, public headers are simple umbrella headers so there isn't
much code in the #else branch. In other cases, the #else branch contains
the actual implementation of the header.

show more ...


Revision tags: llvmorg-19.1.6
# c166a9c7 10-Dec-2024 Nikolas Klauser <nikolasklauser@berlin.de>

[libc++] Add #if 0 block to all the top-level headers (#119234)

Including The frozen C++03 headers results in a lot of formatting
changes in the main headers, so this splits these changes into a
sep

[libc++] Add #if 0 block to all the top-level headers (#119234)

Including The frozen C++03 headers results in a lot of formatting
changes in the main headers, so this splits these changes into a
separate commit instead.

This is part of
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.

show more ...


# 4c4606a7 09-Dec-2024 Louis Dionne <ldionne.2@gmail.com>

[libc++] Add missing assertion in std::span constructor (#118396)

The (iterator, size) constructor should ensure that it gets passed a
valid range when the size is not 0.

Fixes #107789


Revision tags: llvmorg-19.1.5, llvmorg-19.1.4
# e99c4906 31-Oct-2024 Nikolas Klauser <nikolasklauser@berlin.de>

[libc++] Granularize <cstddef> includes (#108696)


Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0
# 7a785d46 04-Sep-2024 Louis Dionne <ldionne.2@gmail.com>

[libc++][modules] Use inline variable instead of true_type (#106797)

This allows breaking up a dependency from __fwd/array.h onto
__type_traits, which is a circular dependency once __type_traits be

[libc++][modules] Use inline variable instead of true_type (#106797)

This allows breaking up a dependency from __fwd/array.h onto
__type_traits, which is a circular dependency once __type_traits becomes
a module of its own. This is also a small consistency improvement since
we've been using inline variables for traits like this elsewhere in the
library.

show more ...


Revision tags: llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3
# 99696b35 16-Aug-2024 Louis Dionne <ldionne.2@gmail.com>

[libc++] Fix rejects-valid in std::span copy construction (#104500)

Trying to copy-construct a std::span from another std::span holding an
incomplete type would fail as we evaluate the SFINAE for t

[libc++] Fix rejects-valid in std::span copy construction (#104500)

Trying to copy-construct a std::span from another std::span holding an
incomplete type would fail as we evaluate the SFINAE for the range-based
constructor. The problem was that we checked for __is_std_span after
checking for the range being a contiguous_range, which hard-errored
because of arithmetic on a pointer to incomplete type.

As a drive-by, refactor the whole test and format it.

Fixes #104496

show more ...


Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init
# e2c2ffbe 18-Jun-2024 Louis Dionne <ldionne.2@gmail.com>

[libc++][NFC] Run clang-format on libcxx/include again (#95874)

As time went by, a few files have become mis-formatted w.r.t.
clang-format. This was made worse by the fact that formatting was not

[libc++][NFC] Run clang-format on libcxx/include again (#95874)

As time went by, a few files have become mis-formatted w.r.t.
clang-format. This was made worse by the fact that formatting was not
being enforced in extensionless headers. This commit simply brings all
of libcxx/include in-line with clang-format again.

We might have to do this from time to time as we update our clang-format
version, but frankly this is really low effort now that we've formatted
everything once.

show more ...


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7
# 38bf6840 05-Jun-2024 Louis Dionne <ldionne.2@gmail.com>

[libc++] Add missing noexcept to span constructor (#94381)

Thanks to Marshall Clow for noticing.
Fixes #94364


Revision tags: llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4
# 7cafe04e 12-Apr-2024 Xiaoyang Liu <siujoeng.lau@gmail.com>

[libc++] P3029R1: Better `mdspan`'s CTAD (#87873)

## Abstract

This pull request implements [P3029R1](https://wg21.link/P3029R1). The
paper discusses the current behavior of `mdspan`'s most commo

[libc++] P3029R1: Better `mdspan`'s CTAD (#87873)

## Abstract

This pull request implements [P3029R1](https://wg21.link/P3029R1). The
paper discusses the current behavior of `mdspan`'s most common
pointer-indices CTAD, where the `Extents` template parameter is deduced
as `dextents` (dynamic extents), even when passing compile-time constant
values. The author believes this behavior is suboptimal, as it doesn't
take advantage of the compile-time information. The proposed change
suggests deducing static extents if `integral_constant`-like constants
are passed, resulting in more intuitive syntax and less error-prone
code.

## Reference

- [P3029R1](https://wg21.link/P3029R1)
- [Draft C++ Standard: [span.syn]](https://eel.is/c++draft/span.syn)
- [Draft C++ Standard: [mdspan.syn]](https://eel.is/c++draft/mdspan.syn)

show more ...


Revision tags: llvmorg-18.1.3, llvmorg-18.1.2
# ee22e255 09-Mar-2024 Nikolas Klauser <nikolasklauser@berlin.de>

[libc++] Remove <array> include from <span> (#83742)

This reduces the include time of `<span>` from 122ms to 78ms.


Revision tags: llvmorg-18.1.1
# 8e4887ff 06-Mar-2024 Nikolas Klauser <nikolasklauser@berlin.de>

[libc++][NFC] Remove redundant preprocessor directive


# 37dca605 29-Feb-2024 Louis Dionne <ldionne.2@gmail.com>

[libc++] Clean up includes of <__assert> (#80091)

Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
th

[libc++] Clean up includes of <__assert> (#80091)

Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
that mechanism anymore, we don't need to declare __libcpp_verbose_abort
from all public headers, and we can clean up a lot of unnecessary
includes.

This patch also moves the definition of the various assertion categories
to the <__assert> header, since we now rely on regular IWYU for these
assertion macros.

rdar://105510916

show more ...


Revision tags: 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
# dbbeee6b 20-Jan-2024 Hristo Hristov <hristo.goshev.hristov@gmail.com>

[libc++][span] P2447R4: `std::span` over an initializer list (#78157)

Implements: https://wg21.link/P2447R6
- https://eel.is/c++draft/span.syn
- https://eel.is/c++draft/span.overview
- https://ee

[libc++][span] P2447R4: `std::span` over an initializer list (#78157)

Implements: https://wg21.link/P2447R6
- https://eel.is/c++draft/span.syn
- https://eel.is/c++draft/span.overview
- https://eel.is/c++draft/span.cons
- https://eel.is/c++draft/diff

---------

Co-authored-by: Zingam <zingam@outlook.com>

show more ...


# a72ab9c1 05-Jan-2024 Hristo Hristov <hristo.goshev.hristov@gmail.com>

[libc++][span] P2821R5: `span.at()` (#74994)

- Implements: [P2821R5: span.at()](https://wg21.link/P2821R5)
(https://eel.is/c++draft/views.contiguous#views.span)
- Cleaned up `span.operator[]` te

[libc++][span] P2821R5: `span.at()` (#74994)

- Implements: [P2821R5: span.at()](https://wg21.link/P2821R5)
(https://eel.is/c++draft/views.contiguous#views.span)
- Cleaned up `span.operator[]` test

---------

Co-authored-by: Zingam <zingam@outlook.com>

show more ...


# 9783f28c 18-Dec-2023 Louis Dionne <ldionne.2@gmail.com>

[libc++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmar

[libc++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.

This patch was generated with:

find libcxx/include libcxx/src -type f \
| grep -v 'module.modulemap.in' \
| grep -v 'CMakeLists.txt' \
| grep -v 'README.txt' \
| grep -v 'libcxx.imp' \
| grep -v '__config_site.in' \
| xargs clang-format -i

A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.

[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all

show more ...


# 77a00c0d 05-Dec-2023 Louis Dionne <ldionne.2@gmail.com>

[libc++] Replace uses of _VSTD:: by std:: (#74331)

As part of the upcoming clang-formatting of libc++, this patch performs
the long desired removal of the _VSTD macro.

See https://discourse.llvm

[libc++] Replace uses of _VSTD:: by std:: (#74331)

As part of the upcoming clang-formatting of libc++, this patch performs
the long desired removal of the _VSTD macro.

See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.

show more ...


# b18a46e3 04-Dec-2023 Louis Dionne <ldionne.2@gmail.com>

[libc++][NFC] Add a few clang-format annotations (#74352)

This is in preparation for clang-formatting the whole code base. These
annotations are required either to avoid clang-format bugs or becaus

[libc++][NFC] Add a few clang-format annotations (#74352)

This is in preparation for clang-formatting the whole code base. These
annotations are required either to avoid clang-format bugs or because
the manually formatted code is significantly more readable than the
clang-formatted alternative. All in all, it seems like very few
annotations are required, which means that clang-format is doing a very
good job in most cases.

show more ...


# 4c198542 04-Dec-2023 Louis Dionne <ldionne.2@gmail.com>

[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)

In preparation for running clang-format on the whole code base, we are
also removing mentions of the legacy _LIBCPP_INLIN

[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)

In preparation for running clang-format on the whole code base, we are
also removing mentions of the legacy _LIBCPP_INLINE_VISIBILITY macro in
favor of the newer _LIBCPP_HIDE_FROM_ABI.

We're still leaving the definition of _LIBCPP_INLINE_VISIBILITY to avoid
creating needless breakage in case some older patches are checked-in
with mentions of the old macro. After we branch for LLVM 18, we can do
another pass to clean up remaining uses of the macro that might have
gotten introduced by mistake (if any) and remove the macro itself at the
same time. This is just a minor convenience to smooth out the transition
as much as possible.

See
https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.

show more ...


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4
# a65070a7 29-Oct-2023 philnik777 <nikolasklauser@berlin.de>

[libc++] Remove a few transitive includes (#70553)


Revision tags: 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
# 4122db1f 20-Jul-2023 varconst <varconsteq@gmail.com>

[libc++][hardening] Categorize most assertions inside the container classes.

This introduces:
- `_LIBCPP_ASSERT_VALID_INPUT_RANGE`;
- `_LIBCPP_ASSERT_VALID_CONTAINER_ACCESS`;
- `_LIBCPP_ASSERT_VALID

[libc++][hardening] Categorize most assertions inside the container classes.

This introduces:
- `_LIBCPP_ASSERT_VALID_INPUT_RANGE`;
- `_LIBCPP_ASSERT_VALID_CONTAINER_ACCESS`;
- `_LIBCPP_ASSERT_VALID_ITERATOR_ACCESS`;
- `_LIBCPP_ASSERT_VALID_ALLOCATOR`;
- `_LIBCPP_ASSERT_INTERNAL`.

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

show more ...


# 00e740f1 19-Jun-2023 Mark de Wever <koraq@xs4all.nl>

[NFC][libc++] Addresses LWG3903.

Note libc++ actually implemented this wording from the start (D49338).
The Clang version is the same as the version that implements
P0122R7 <span>

Implements
- LW

[NFC][libc++] Addresses LWG3903.

Note libc++ actually implemented this wording from the start (D49338).
The Clang version is the same as the version that implements
P0122R7 <span>

Implements
- LWG3903 span destructor is redundantly noexcept

Reviewed By: #libc, philnik

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

show more ...


# b5270ba2 29-Jun-2023 varconst <varconsteq@gmail.com>

[libc++] Remove the legacy debug mode.

See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026

Reviewed By: #libc, Mordante, ldionne

Differential Revision: https://revi

[libc++] Remove the legacy debug mode.

See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026

Reviewed By: #libc, Mordante, ldionne

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

show more ...


# cd0ad421 27-Jun-2023 varconst <varconsteq@gmail.com>

[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.

Replace most uses of `_LIBCPP_ASSERT` with
`_LIBCPP_ASSERT_UNCATEGORIZED`.

This is done as a prerequisite to introducing hardened

[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.

Replace most uses of `_LIBCPP_ASSERT` with
`_LIBCPP_ASSERT_UNCATEGORIZED`.

This is done as a prerequisite to introducing hardened mode to libc++.
The idea is to make enabling assertions an opt-in with (somewhat)
fine-grained controls over which categories of assertions are enabled.
The vast majority of assertions are currently uncategorized; the new
macro will allow turning on `_LIBCPP_ASSERT` (the underlying mechanism
for all kinds of assertions) without enabling all the uncategorized
assertions (in the future; this patch preserves the current behavior).

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

show more ...


# be02f912 27-Jun-2023 varconst <varconsteq@gmail.com>

[libc++][hardening] Add an ABI macro `_LIBCPP_ABI_BOUNDED_ITERATORS`.

Use the new macro instead of `_LIBCPP_DEBUG_ITERATOR_BOUNDS_CHECKING`.

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


Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2
# 3865e084 11-Apr-2023 Louis Dionne <ldionne.2@gmail.com>

[libc++] Remove redundant assertion in std::span::subspan

That is already checked later in the function as `__count <= size() - __offset`.

rdar://107884996

Differential Revision: https://reviews.l

[libc++] Remove redundant assertion in std::span::subspan

That is already checked later in the function as `__count <= size() - __offset`.

rdar://107884996

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

show more ...


1234