This commit adds a new helper function: `getSingleElement`
This function asserts that the container has a single element and then
returns that element. This helper function is useful during 1:N dialect
conversions in MLIR, where certain `ValueRange`s (returned from the
adaptor) are known to have a single value.
This is to make sure that ADT helpers consistently use argument
dependent lookup when dealing with input ranges.
This was a part of https://github.com/llvm/llvm-project/pull/87936 but
reverted due to buildbot failures.
This is to make sure that ADT helpers consistently use argument
dependent lookup when dealing with input ranges.
This was a part of #87936 but reverted due to buildbot failures.
Also add `map_range` unit tests -- there were no pre-existing tests
AFAICT.
This is to make sure that ADT helpers consistently use argument
dependent lookup when dealing with input ranges.
This was a part of #87936 but reverted due to buildbot failures.
Also fix potential issue with double-move on the input range.
This is to make sure that ADT helpers consistently use argument
dependent lookup when dealing with input ranges.
This was a part of #87936 but reverted due to buildbot failures.
This is to make sure that ADT helpers consistently use argument
dependent lookup when dealing with input ranges.
This was a part of #87936 but reverted due to buildbot failures.
Also clean up the implementation to adhere to the llvm coding standards.
This is to make sure that ADT helpers consistently use argument
dependent lookup when dealing with input ranges.
This was a part of #87936 but reverted due to buildbot failures.
This is to make sure that ADT helpers consistently use argument
dependent lookup when dealing with input ranges.
This was a part of #87936 but reverted due to buildbot failures. Now
that I have a threadripper system, I'm landing this piece-by-piece.
If any iterator in the concatenation returns by value, the result must
return by value otherwise it'll produce dangling references.
(some context that may or may not be relevant to this part of the code
may be in
981ce8fa15
)
An alternative to #112441
The previous `all_equal` implementation contained `Begin + 1`, which
implicitly requires `Begin` to model the
[random_access_iterator](https://en.cppreference.com/w/cpp/iterator/random_access_iterator)
concept due to the usage of the `+` operator. By swapping this out with
`std::next`, this method can be used with weaker iterator concepts, such
as
[forward_iterator](https://en.cppreference.com/w/cpp/iterator/forward_iterator).
---------
Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>
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.
Currently there are two versions of llvm::unique, one that requires a
predicate, and is in STLExtras.h; and one that does not require a
predicate, and is in GenericUniformityImpl.h. This moves the one from
GenericUniformityImp.h to STlExtras.h, so they are both together, and
can both be easily called from other places inside LLVM.
This is so that we can append multiple values at once without having to
create a temporary array or repeatedly call `push_back`.
Use the new function `append_values` to clean up the SPIR-V serializer
code. (NFC)
This allows us to produce better error messages for types that were only
forward-declared, but where a full definition was expected.
The first user will be https://reviews.llvm.org/D159013; this change is
sent to review separately to reduce the scope of the other patch.
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
This does not work by a mere composition of `enumerate` and `zip_equal`,
because C++17 does not allow for recursive expansion of structured
bindings.
This implementation uses `zippy` to manage the iteratees and adds the
stream of indices as the first zipped range. Because we have an upfront
assertion that all input ranges are of the same length, we only need to
check if the second range has ended during iteration.
As a consequence of using `zippy`, `enumerate` will now follow the
reference and lifetime semantics of the `zip*` family of functions. The
main difference is that `enumerate` exposes each tuple of references
through a new tuple-like type `enumerate_result`, with the familiar
`.index()` and `.value()` member functions.
Because the `enumerate_result` returned on dereference is a
temporary, enumeration result can no longer be used through an
lvalue ref.
Reviewed By: dblaikie, zero9178
Differential Revision: https://reviews.llvm.org/D144503
This makes it so that calling `llvm::is_contained` no longer degrades
performance over member contains, even though both have almost identical
names. This would be the case in most set/map classes that can check for
an element being present in O(1) or O(log n) time vs. linear scan with
`std::find`. For C++17 maps/sets without `.contains`, use `.find` when available,
falling back to a linear scan with `std::find`.
I also considered detecting member contains and triggering a
`static_assert` instead, but decided against it because it's just as easy
to do the right thing and call `.contains`. This would also make some code fail
only when compiled in the C++20 mode when more container types come with
`.contains` member functions.
This was actually already the case with `CommandLine.h` calling `is_contained`
on `SmallPtrSet` and in a recent BOLT patch.
Reviewed By: kazu, dblaikie, MaskRay
Differential Revision: https://reviews.llvm.org/D146061
Update less_first,less_second to use std::get to access the first and
second component. This extends support to any type implementing
std::get, like tuples.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D145489
The issue seems to be caused by the definition of `SafeIntIterator` and
is otherwise unrelated to the implementation of `append_range`.
We have a simialr test below, so this does not meaningfully decrease the
test coverage of `append_range`.
See the discussion in: https://reviews.llvm.org/D144420#4164373
Issue: https://github.com/llvm/llvm-project/issues/61122
This allows `enumerate` to work with range types that expose custom
`begin`/`end` functions.
This is a cleanup in preparation for future changes in
https://reviews.llvm.org/D144503.
Reviewed By: zero9178
Differential Revision: https://reviews.llvm.org/D145026
- Make `IterOfRange` and `ValueOfRange` work with types that require
custom `begin`/`end` functions.
- Allow for `adl_begin`/`adl_end` to be used in constant-evaluated
contexts.
- Use SFINAE-friendly trailing return type deductions `adl_begin`/`adl_end` so that they are useable in template argument deduction.
- Add missing documentation comments.
This is required for future work in https://reviews.llvm.org/D144503.
Reviewed By: dblaikie, zero9178
Differential Revision: https://reviews.llvm.org/D144583
This makes `append_range` useable with, C arrays and types with custom
`begin`/`end` functions.
Reviewed By: kazu
Differential Revision: https://reviews.llvm.org/D144420
- Do not require both the `Set` and `Element` to be exactly the same type and, instead, only require them to be comparable.
- Do not require `Element` to be copyable.
- Add missing documentation comment.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D144416
This patch deprecates llvm::empty as I've migrated all known uses of
llvm::empty(x) to x.empty().
Differential Revision: https://reviews.llvm.org/D134141
`llvm::all_equal` checks if all values in the given range are equal, i.e., there are no two elements that are not equal.
Similar to `llvm::all_of`, it returns `true` when the range is empty.
`llvm::all_equal` is intended to supersede `llvm::is_splat`, which will be deprecated and removed in future patches.
See the discussion thread for more details:
https://discourse.llvm.org/t/adt-is-splat-and-empty-ranges/64692.
Reviewed By: dblaikie, shchenz
Differential Revision: https://reviews.llvm.org/D132334
This patch adds the ability to deconstruct the `value_type` returned by `llvm::enumarate` into index and value of the wrapping range. Main use case is the common occurence of using it during loop iteration. After this patch it'd then be possible to write code such as:
```
for (auto [index, value] : enumerate(container)) {
...
}
```
where `index` is the current index and `value` a reference to elements in the given container.
Differential Revision: https://reviews.llvm.org/D131486
Allow for `is_splat` to be used inline, similar to `is_contained`, e.g.,
```
if (is_splat({type1, type2, type3, type4}))
...
```
which is much more concise and less typo-prone than an equivalent chain of equality comparisons.
My immediate motivation is to clean up some code in the SPIR-V dialect that currently needs to either construct a temporary container or use `makeArrayRef` before calling `is_splat`.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D131289
clang may throw the following warning:
include/clang/AST/DeclarationName.h:210:52: error: arithmetic between
different enumeration types ('clang::DeclarationName::StoredNameKind'
and 'clang::detail::DeclarationNameExtra::ExtraKind') is deprecated
when flags -Werror,-Wdeprecated-enum-enum-conversion are on.
This adds the `addEnumValues()` helper function to STLExtras.h to hide
the details of adding enumeration values together from two different
enumerations.
Adding an initializer list specialization for is_contained allows for
compile-time evaluation when called with a constant or runtime
evaluation for non-constant values.
This patch doesn't add any uses of this template, but that is coming in
a subsequent patch.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D122079
This patch adds drop_end that is analogical to drop_begin.
It tries to fill the functional gap where one could drop first elements but not the last ones.
The need for it came in when refactoring clang-format.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122009
Similar versions of these already exist, this effectively just just
factors them out into STLExtras. I plan to use these in future patches.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D100672
This takes two ranges and invokes a predicate on the element-wise pair in the
ranges. It returns true if all the pairs are matching the predicate and the ranges
have the same size.
It is useful with containers that aren't random iterator where we can't check the
sizes in O(1).
Differential Revision: https://reviews.llvm.org/D106605
Address mistakenly comparing the pointer values of two C-style strings
rather than comparing their contents in the unit tests for makeVisitor,
added in 6d6f35eb7b92c6dd4478834497752f4e963db16d
Relands patch reverted by 61242c0addb120294211d24a97ed89837418cb36
The original patch mistakenly included unrelated tests.
Adds a utility to combine multiple Callables into a single Callable.
This is useful to make constructing a visitor for `std::visit`-like
functions more natural; functions like this will be added in future
patches.
Intended to supercede https://reviews.llvm.org/D99560 by
perfectly-forwarding the combined Callables.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D100670
Adds a utility to combine multiple Callables into a single Callable.
This is useful to make constructing a visitor for `std::visit`-like
functions more natural; functions like this will be added in future
patches.
Intended to supercede https://reviews.llvm.org/D99560 by
perfectly-forwarding the combined Callables.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D100670
Preparation for landing the tests for llvm::makeVisitor, including
breaking out the a "Counted" base class and explicitly testing
the prvalue case as distinct from the rvalue case.
Differential Revision: https://reviews.llvm.org/D103206
Similar versions of these already exist, this effectively just just
factors them out into STLExtras. I plan to use these in future patches.
Differential Revision: https://reviews.llvm.org/D100672
This patch adds the default value of 1 to drop_begin.
In the llvm codebase, 70% of calls to drop_begin have 1 as the second
argument. The interface similar to with std::next should improve
readability.
This patch converts a couple of calls to drop_begin as examples.
Differential Revision: https://reviews.llvm.org/D94858
