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 ...
|