libcollections: Fix RingBuf growth for non-power-of-two capacities

[Ryman]

See test for details.

[brson]

I don't see what the bug was. It was requesting to reserve a particular size, which means the vec will definitely reserve at least that much, so it looks like the worst that should have happened was that excess capacity was wasted. What was actually happening to cause a bug?

Extending the ringbuf to whatever capacity the vector decided to create seems like it could affect the ringbuf algorithm in subtle ways. Does the ringbuf care about growing in exact sizes of two?

[huonw]

Does the ringbuf care about growing in exact sizes of two?

If it guarantees that it is always a power of two, it can be more efficient by using shifts/bitmasking instead of divisions/remainders for computing the wrapped-around indexes (etc.).

[Ryman]

@brson The RingBuf itself doesn't seem to care about power of two currently, but it was making assumptions about the growth of the underlying vector which lead to indexing being wrong.

E.g. grow requests a new length of 6 (3*2), it gets a capacity of 8 (vec grows by power of two) but does all its move calculations based on 6 which leaves gaps in the underlying vector so the lo counter doesn't wrap before it meets a None value, which then fails.

[brson]

@huonw It doesn't seem to be doing that. I don't see any power-of-two assumptions in the code.

[lilyball]

@brson The rest of the grow() function, that doesn't show up in the diff, uses newlen as if it were the capacity of the vector. If the vector reserved more space than was requested, this left a bunch of Nones at the end of the vector, after the elements that were supposed to be attached to the end.

[huonw]

@brson yes, it's not currently doing that, it was merely a related possible optimisation.