Remove Uses of std::iterator from VTR Libraries about vtr-verilog-to-routing

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