diff options
author | Jakub Kuderski <kubak@google.com> | 2023-03-15 19:34:21 -0400 |
---|---|---|
committer | Jakub Kuderski <kubak@google.com> | 2023-03-15 19:34:22 -0400 |
commit | a0a76804c4b56058ba3dcd7374bcaec2fec3978e (patch) | |
tree | 4d7f85f08c851a2007e5e3319a136b9868ae6c47 /llvm/lib/CodeGen/MachineFunction.cpp | |
parent | ac1d143b0ef924cf2725bb36537f18ae2c7f9c4f (diff) | |
download | llvm-a0a76804c4b56058ba3dcd7374bcaec2fec3978e.zip llvm-a0a76804c4b56058ba3dcd7374bcaec2fec3978e.tar.gz llvm-a0a76804c4b56058ba3dcd7374bcaec2fec3978e.tar.bz2 |
[ADT] Allow `llvm::enumerate` to enumerate over multiple ranges
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
Diffstat (limited to 'llvm/lib/CodeGen/MachineFunction.cpp')
0 files changed, 0 insertions, 0 deletions