All `proc_*` passes now use the same module and process for loops, using `design->all_selected_modules()` and `mod->selected_processes()` respectively.
This simplifies the code, and makes the couple `proc_*` passes that were ignoring boxed modules stop doing that (which seems to have been erroneous rather than intentional).
* early return caused proc_dff to stop considering rules after seeing
one async rule - this is because continue should have been used to
continue to procecssing the next rule instead of returning from the
function
* This fixes#4560, where previously the order that sync rules were
processed in depended on the order they were pulled out of a std::map.
This PR changes this to process them in the order they are found in,
respecting the priorities among the async signals
See the test case. PROC_ROM will consider this for evaluation, even
though -- without any actions -- lhs is empty (but still "uniform").
A zero-width memory is constructed, which later fails check with:
ERROR: Assert `width != 0' failed in kernel/mem.cc:518.
Ensure we don't proceed if there's nothing to encode.
An `std::vector<T>::reverse_iterator` stores the
`std::vector<T>::iterator` which points to the (forwards-ordered)
*following* item. Thus while `vec.rbegin()` dereferences to the final
item of `vec`, the iterator it wraps (`vec.rbegin().base()`) is equal to
`vec.end()`.
In the remove case here, we advance `it` (backwards), erasing the item
we just advanced past by grabbing its (pre-increment) base
forward-iterator and subtracting 1.
The iterator maths here is obviously all OK, but the forward-iterator
that `it` wraps post-increment actually points to the item we just
removed. That iterator was invalidated by the `erase()` call.
That this works anyway is (AFAICT) some combination of luck and/or
promises that aren't part of the C++ spec, but MSVC's debug iterator
support picks this up.
`erase()` returns the new iterator that follows the item just erased,
which happens to be the exact one we want our reverse-iterator to wrap
for the next loop; we get a fresh iterator to the same base, now without
the preceding item.
