Remove Uses of std::iterator from VTR Libraries

[AlexandreSinger]

The std::iterator class will be deprecated in C++17:

• https://stackoverflow.com/questions/43268146/why-is-stditerator-deprecated

In CI, the GCC 12 and CLANG 14 build show the deprecation warnings. There are other warnings in these builds, but the std::iterator warnings are blocking most of them.

This is fine right now since the CI is currently on Ubuntu 22.04, which comes with GCC 11.4 built-in; however, in the near future we should upgrade the CI to Ubuntu 24.04, which comes with GCC 13.3 built-in. GCC 13 is not even being tested by CI yet, but it will have the same deprecation warnings (if not these features will actually be deprecated).

We should begin to transition the use of std::iterator into their own classes. The process seems to be pretty standard, it would just require some work since some of the uses of std::iterator are in external libraries.

The current users of std::iterator in VTR are:

• [x] librrgraph/src/base/rr_node_impl.h
• [x] librrgraph/src/base/rr_node_types.h
• [x] libvtrutil/src/vtr_array_view.h
• [x] libvtrutil/src/vtr_ragged_matrix.h
• [x] libvtrutil/src/vtr_vector.h
• [x] EXTERNAL/libtatum/libtatum/tatum/tags/TimingTags.hpp
• [x] EXTERNAL/capnproto/c++/src/capnp/compat/std-iterator.h
• [ ] yosys: Yosys contains deprecation warnings for std::iterator which were resolved in recent versions of Yosys. See discussion below.

There may be more, but these were the ones I could find with grep. Once we clear most of these, some other may become more clear from the CI.

[AlexandreSinger]

This resource provides a good description of how to define a custom iterator in modern C++:

• https://internalpointers.com/post/writing-custom-iterators-modern-cpp

Their description of the different properties expected to be implemented is quite good:

As well as a description of why adding these arguments are important:

[AlexandreSinger]

libvtrutil/src/vtr_array_view.h and libvtrutil/src/vtr_vector.h, beyond just having obviously duplicated code, have this strange comment and style of declaring something called "my_iter". I find this very strange, and I am not sure how to proceed in this case since it appears to rely on the fact that we are using std::iterator here; but I do not think this is necessary.

[vaughnbetz]

Thanks @AlexandreSinger . No strong preference on how you fix this, but I agree it is good to update. Pushing back to libtatum/upstreaming should be easy. capnproto won't be so easy; maybe the latest version of capnproto gets rid of this?

[AlexandreSinger]

@vaughnbetz Looks like you were correct. Capnproto fixed this issue 2 years ago:

This means that we may need to upgrade our version of capnproto if we want to 100% remove these warnings. Once the other uses of std::iterator are removed we can decide what to do from there. Based on the git history, we are currently on capnproto v0.9.1

In order to resolve this, we would need to rebase ourselves onto capnproto v1.0.0 at least. (v1.0.2 is the latest). I think we should update to the most recent release version (v1.0.2).

[vaughnbetz]

Thanks @AlexandreSinger . Yes, rebasing onto the latest seems like the best approach. Of course, we should change one thing at a time, so sorting the other iterators before trying the upgrade makes sense!

[AlexandreSinger]

Through looking through the CI logs, it looks like there were uses of std::iterator in Yosys as well that I did not originally see (blocked by too many warnings).

Currently we are on yosys-0.32. The developers of Yosys fixed this issue in yosys-0.37 (yosys-0.41 is the latest). Looks like we may need to upgrade Yosys as well.

@vaughnbetz I agree, we should change one thing at a time. Hopefully these upgrades go smoothly.

[vaughnbetz]

Sounds good. Upgrading to the latest yosys makes sense. Good topics for the vtr meeting Thursday. We should probably make a table (or slide deck) of planned upgrades and try to assign owners and a sequence.