History log of /llvm-project/llvm/unittests/ADT/IteratorTest.cpp (Results 1 – 25 of 40)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4
# c8f3d211 06-Apr-2024 Jakub Kuderski <jakub@nod-labs.com>

[ADT] Allow reverse to find free rbegin/rend functions (#87840)

Lift the requirement that rbegin/rend must be member functions. Also
allow the rbegin/rend to be found through Argument Dependent Loo

[ADT] Allow reverse to find free rbegin/rend functions (#87840)

Lift the requirement that rbegin/rend must be member functions. Also
allow the rbegin/rend to be found through Argument Dependent Lookup
(ADL) and add `adl_rbegin`/`adl_rend` to STLExtras.

show more ...


Revision tags: 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
# 40dc8e68 27-Sep-2023 Gregory Alfonso <gfunni234@gmail.com>

[NFC] Use const references to avoid copying objects in for-loops

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


Revision tags: 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
# 29818325 21-Mar-2023 Jakub Kuderski <kubakuderski@gmail.com>

[ADT] Add `llvm::range_size` function for generic ranges

This function follows `std::ranges::size` from C++20. It is intended
mainly for generic code that does not know the exact range type.
I did n

[ADT] Add `llvm::range_size` function for generic ranges

This function follows `std::ranges::size` from C++20. It is intended
mainly for generic code that does not know the exact range type.
I did not modify the existing `llvm::size` function because it has a strict
guarantee of O(1) running time, and we cannot guarantee that when we delegate
size check to user-defined size functions.

Use `range_size` to optimize size checks in `zip`* and `enumerate`
functions. Before that, we would have to perform linear scans for ranges
without random access iterators.

This is the last change I have planned in the series that overhauls
`zip`* and `enumerate`.

Reviewed By: dblaikie, zero9178

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

show more ...


Revision tags: llvmorg-16.0.0, llvmorg-16.0.0-rc4
# 38774c4f 06-Mar-2023 Jakub Kuderski <kubak@google.com>

[ADT] Avoid needless iterator copies in `zippy`

Make `zip_common` increment and decrement iterators in place.

This improves performance with iterator types that have non-triviall
copy constructors.

[ADT] Avoid needless iterator copies in `zippy`

Make `zip_common` increment and decrement iterators in place.

This improves performance with iterator types that have non-triviall
copy constructors.

Reviewed By: zero9178

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

show more ...


# 981ce8fa 28-Feb-2023 Jakub Kuderski <kubak@google.com>

[ADT] Fix const-correctness issues in `zippy`

This defines the iterator tuple based on the storage type of `zippy`,
instead of its type arguments. This way, we can support temporaries that
gets pass

[ADT] Fix const-correctness issues in `zippy`

This defines the iterator tuple based on the storage type of `zippy`,
instead of its type arguments. This way, we can support temporaries that
gets passed in and allow for them to be modified during iteration.

Because the iterator types to the tuple storage can have different types
when the storage is and isn't const, this defines a const iterator type
and non-const `begin`/`end` functions. This way we avoid unintentional
casts, e.g., trying to cast `vector<bool>::reference` to
`vector<bool>::const_reference`, which may be unrelated types that are
not convertible.

This patch is a general and free-standing improvement but my primary use
is in the implemention a version of `enumerate` that accepts multiple ranges:
D144583.

Reviewed By: dblaikie, zero9178

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

show more ...


Revision tags: llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7
# e52b9bf6 09-Dec-2022 Krzysztof Parzyszek <kparzysz@quicinc.com>

[STLExtras] Convert deref_or_none and zip_longest to std::optional


# b6a01caa 03-Dec-2022 Kazu Hirata <kazu@google.com>

[llvm/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the am

[llvm/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


# 21d434d9 30-Nov-2022 Jakub Kuderski <kubak@google.com>

[ADT] Add `zip_equal` for iteratees of equal lengths

Add a new version of `zip` that assumes that all iteratees have equal
lengths. The difference compared to `zip_first` is that `zip_equal`
checks

[ADT] Add `zip_equal` for iteratees of equal lengths

Add a new version of `zip` that assumes that all iteratees have equal
lengths. The difference compared to `zip_first` is that `zip_equal`
checks this assumption in builds with assertions enabled.

This will allow us to clearly express the intent when working with
equally-sized ranges without having to write this assertion manually.

This is similar to Python's `zip(..., equal=True)` [1] or
`more_itertools.zip_equal` [2].

I saw this first suggested by @benvanik.

[1] https://peps.python.org/pep-0618/
[2] https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.zip_equal

Reviewed By: dblaikie

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

show more ...


# aa7a3d4d 30-Nov-2022 Jakub Kuderski <kubak@google.com>

[ADT] Clarify `zip` behavior with iteratees of different lengths

Update the documentation comment and add a new test case.

Add an assertion in `zip_first` checking the iteratee length precondition.

[ADT] Clarify `zip` behavior with iteratees of different lengths

Update the documentation comment and add a new test case.

Add an assertion in `zip_first` checking the iteratee length precondition.

Reviewed By: dblaikie

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

show more ...


Revision tags: llvmorg-15.0.6, llvmorg-15.0.5
# 6aa050a6 08-Nov-2022 Nathan James <n.james93@hotmail.co.uk>

Reland "[llvm][NFC] Use c++17 style variable type traits"

This reverts commit 632a389f96355cbe7ed8fa7b8d2ed6267c92457c.

This relands commit
1834a310d060d55748ca38d4ae0482864c2047d8.

Differential R

Reland "[llvm][NFC] Use c++17 style variable type traits"

This reverts commit 632a389f96355cbe7ed8fa7b8d2ed6267c92457c.

This relands commit
1834a310d060d55748ca38d4ae0482864c2047d8.

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

show more ...


# 632a389f 08-Nov-2022 Nathan James <n.james93@hotmail.co.uk>

Revert "[llvm][NFC] Use c++17 style variable type traits"

This reverts commit 1834a310d060d55748ca38d4ae0482864c2047d8.


# 1834a310 08-Nov-2022 Nathan James <n.james93@hotmail.co.uk>

[llvm][NFC] Use c++17 style variable type traits

This was done as a test for D137302 and it makes sense to push these changes

Reviewed By: dblaikie

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

[llvm][NFC] Use c++17 style variable type traits

This was done as a test for D137302 and it makes sense to push these changes

Reviewed By: dblaikie

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

show more ...


Revision tags: llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2
# f7b73b7e 06-Aug-2022 Markus Böck <markus.boeck02@gmail.com>

[llvm] Remove uses of deprecated `std::iterator`

std::iterator has been deprecated in C++17 and some standard library implementations such as MS STL or libc++ emit deperecation messages when using t

[llvm] Remove uses of deprecated `std::iterator`

std::iterator has been deprecated in C++17 and some standard library implementations such as MS STL or libc++ emit deperecation messages when using the class.
Since LLVM has now switched to C++17 these will emit warnings on these implementations, or worse, errors in build configurations using -Werror.

This patch fixes these issues by replacing them with LLVMs own llvm::iterator_facade_base which offers a superset of functionality of std::iterator.

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

show more ...


Revision tags: llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# 6b9b86db 12-Nov-2021 Duncan P. N. Exon Smith <dexonsmith@apple.com>

ADT: Fix const-correctness of iterator facade

Fix the const-ness of `iterator_facade_base::operator->` and
`iterator_facade_base::operator[]`. This is a follow-up to
1b651be0465de70cfa22ce4f715d3501

ADT: Fix const-correctness of iterator facade

Fix the const-ness of `iterator_facade_base::operator->` and
`iterator_facade_base::operator[]`. This is a follow-up to
1b651be0465de70cfa22ce4f715d3501a4dcffc1, which fixed const-ness of
various iterator adaptors.

Iterators, like the pointers that they generalize, have two types of
`const`.

- The `const` qualifier on members indicates whether the iterator
itself can be changed. This is analagous to `int *const`.
- The `const` qualifier on return values of `operator*()`,
`operator[]()`, and `operator->()` controls whether the the
pointed-to value can be changed. This is analogous to `const int*`.

If an iterator facade returns a handle to its own state, then T (and
PointerT and ReferenceT) should usually be const-qualified. Otherwise,
if clients are expected to modify the state itself, the field can be
declared mutable or a const_cast can be used.

show more ...


# c3edab8f 12-Nov-2021 Duncan P. N. Exon Smith <dexonsmith@apple.com>

ADT: Avoid repeating iterator adaptor/facade template params, NFC

Take advantage of class name injection to avoid redundantly specifying
template parameters of iterator adaptor/facade base classes.

ADT: Avoid repeating iterator adaptor/facade template params, NFC

Take advantage of class name injection to avoid redundantly specifying
template parameters of iterator adaptor/facade base classes.

No functionality change, although the private typedefs changed in a
couple of cases.

- Added a private typedef HashTableIterator::BaseT, following the
pattern from r207084 / 3478d4b164e8d3eba01f5bfa3fc5bfb287a78b97, to
pre-emptively appease MSVC (maybe it's not necessary anymore but
looks like we do this pretty consistently). Otherwise, I removed
private
- Removed private typedefs filter_iterator_impl::BaseT and
FilterIteratorTest::InputIterator::BaseT since there was only one
use of each and the definition was no longer interesting.

show more ...


# 1b651be0 04-Nov-2021 Duncan P. N. Exon Smith <dexonsmith@apple.com>

ADT: Fix const-correctness of iterator adaptors

This fixes const-correctness of iterator adaptors, dropping non-`const`
overloads for `operator*()`.

Iterators, like the pointers that they generaliz

ADT: Fix const-correctness of iterator adaptors

This fixes const-correctness of iterator adaptors, dropping non-`const`
overloads for `operator*()`.

Iterators, like the pointers that they generalize, have two types of
`const`.

The `const` qualifier on members indicates whether the iterator itself
can be changed. This is analagous to `int *const`.

The `const` qualifier on return values of `operator*()`, `operator[]()`,
and `operator->()` controls whether the the pointed-to value can be
changed. This is analogous to `const int *`.

Since `operator*()` does not (in principle) change the iterator, then
there should only be one definition, which is `const`-qualified. E.g.,
iterators wrapping `int*` should look like:
```
int *operator*() const; // always const-qualified, no overloads
```

ba7a6b314fd14bb2c9ff5d3f4fe2b6525514cada changed `iterator_adaptor_base`
away from this to work around bugs in other iterator adaptors. That was
already reverted. This patch adds back its test, which combined
llvm::enumerate() and llvm::make_filter_range(), adds a test for
iterator_adaptor_base itself, and cleans up the `const`-ness of the
other iterator adaptors.

This also updates the documented requirements for
`iterator_facade_base`:
```
/// OLD:
/// - const T &operator*() const;
/// - T &operator*();

/// New:
/// - T &operator*() const;
```
In a future commit we might also clean up `iterator_facade`'s overloads
of `operator->()` and `operator[]()`. These already (correctly) return
non-`const` proxies regardless of the iterator's `const` qualifier.

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

show more ...


# 09864334 03-Nov-2021 Mehdi Amini <joker.eph@gmail.com>

Revert "Fix iterator_adaptor_base/enumerator_iter to allow composition of llvm::enumerate with llvm::make_filter_range"

This reverts commit ba7a6b314fd14bb2c9ff5d3f4fe2b6525514cada.

Post-commit rev

Revert "Fix iterator_adaptor_base/enumerator_iter to allow composition of llvm::enumerate with llvm::make_filter_range"

This reverts commit ba7a6b314fd14bb2c9ff5d3f4fe2b6525514cada.

Post-commit review showed that the fix implemented wasn't correct, and a
more principled fix is possible.

show more ...


# ba7a6b31 02-Nov-2021 Mehdi Amini <joker.eph@gmail.com>

Fix iterator_adaptor_base/enumerator_iter to allow composition of llvm::enumerate with llvm::make_filter_range

* Properly specify reference type in enumerator_iter
* Fix constness of iterator_adapto

Fix iterator_adaptor_base/enumerator_iter to allow composition of llvm::enumerate with llvm::make_filter_range

* Properly specify reference type in enumerator_iter
* Fix constness of iterator_adaptor_base::operator*

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

show more ...


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1
# 058bc4c8 13-Nov-2019 Lang Hames <lhames@gmail.com>

[ADT] Move drop_begin from iterator_range.h into STLExtras.

Summary:
drop_begin depends on adl_begin/adl_end, which are defined in STLExtras.h,
but we can't just #include STLExtras.h in iterator_ran

[ADT] Move drop_begin from iterator_range.h into STLExtras.

Summary:
drop_begin depends on adl_begin/adl_end, which are defined in STLExtras.h,
but we can't just #include STLExtras.h in iterator_range.h as that would
introduce a circular reference (STLExtras.h already depends on
iterator_range.h). The simplest solution is to move drop_begin into
STLExtras.h, which is a reasonable home for it anyway.

Reviewers: dblaikie

Subscribers: dexonsmith, ributzka, llvm-commits

Tags: #llvm

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

show more ...


Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3
# 7e106445 16-Aug-2019 Jonas Devlieghere <jonas@devlieghere.com>

[ADT] Remove llvm::make_unique utility.

All uses of llvm::make_unique should have been replaced with
std::make_unique. This patch represents the last part of the migration
and removes the utility fr

[ADT] Remove llvm::make_unique utility.

All uses of llvm::make_unique should have been replaced with
std::make_unique. This patch represents the last part of the migration
and removes the utility from LLVM.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 369130

show more ...


# 0eaee545 15-Aug-2019 Jonas Devlieghere <jonas@devlieghere.com>

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...


Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1
# 2946cd70 19-Jan-2019 Chandler Carruth <chandlerc@gmail.com>

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...


Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3
# f57bfd3d 05-Dec-2018 Michael Kruse <llvm@meinersbur.de>

[ADT] Add zip_longest iterators.

Like the already existing zip_shortest/zip_first iterators, zip_longest
iterates over multiple iterators at once, but has as many iterations as
the longest sequence.

[ADT] Add zip_longest iterators.

Like the already existing zip_shortest/zip_first iterators, zip_longest
iterates over multiple iterators at once, but has as many iterations as
the longest sequence.

This means some iterators may reach the end before others do.
zip_longest uses llvm::Optional's None value to mark a
past-the-end value.

zip_longest is not reverse-iteratable because the tuples iterated over
would be different for different length sequences (IMHO for the same
reason neither zip_shortest nor zip_first should be reverse-iteratable;
one can still reverse the ranges individually if that's the expected
behavior).

In contrast to zip_shortest/zip_first, zip_longest tuples contain
rvalues instead of references. This is because llvm::Optional cannot
contain reference types and the value-initialized default does not have
a memory location a reference could point to.

The motivation for these iterators is to use C++ foreach to compare two
lists of ordered attributes in D48100 (SemaOverload.cpp and
ASTReaderDecl.cpp).

Idea by @hfinkel.

This re-commits r348301 which was reverted by r348303.
The compilation error by gcc 5.4 was resolved using make_tuple in the in
the initializer_list.
The compileration error by msvc14 was resolved by splitting
ZipLongestValueType (which already was a workaround for msvc15) into
ZipLongestItemType and ZipLongestTupleType.

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

llvm-svn: 348323

show more ...


# 4db904b3 04-Dec-2018 Michael Kruse <llvm@meinersbur.de>

Revert "[ADT] Add zip_longest iterators"

This reverts commit r348301.

Compilation fails on buildbots with older versions of gcc and msvc.

llvm-svn: 348303


# e6899bf0 04-Dec-2018 Michael Kruse <llvm@meinersbur.de>

[ADT] Add zip_longest iterators

Like the already existing zip_shortest/zip_first iterators, zip_longest
iterates over multiple iterators at once, but has as many iterations as
the longest sequence.

[ADT] Add zip_longest iterators

Like the already existing zip_shortest/zip_first iterators, zip_longest
iterates over multiple iterators at once, but has as many iterations as
the longest sequence.

This means some iterators may reach the end before others do.
zip_longest uses llvm::Optional's None value to mark a
past-the-end value.

zip_longest is not reverse-iteratable because the tuples iterated over
would be different for different length sequences (IMHO for the same
reason neither zip_shortest nor zip_first should be reverse-iteratable;
one can still reverse the ranges individually if that's the expected
behavior).

In contrast to zip_shortest/zip_first, zip_longest tuples contain
rvalues instead of references. This is because llvm::Optional cannot
contain reference types and the value-initialized default does not have
a memory location a reference could point to.

The motivation for these iterators is to use C++ foreach to compare two
lists of ordered attributes in D48100 (SemaOverload.cpp and
ASTReaderDecl.cpp).

Idea by @hfinkel.

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

llvm-svn: 348301

show more ...


12