refactor: Replace the bisection dependency

[musicinmybrain]

The bisection crate appears unmaintained (last commit four years ago), and has a couple of unaddressed issues. Since Rust 1.52, we can rely on the standard library and use partition_point instead.

Comparing the definition of partition_point with the definitions of bisect_left and bisect_right, I believe this replacement should be exactly equivalent. However, I don’t believe the test coverage is sufficient to catch any subtle errors here, so I recommend closely double-checking my work.

[baszalmstra]

Awesome! The less dependencies the better.

What do you think is missing with regard to test coverage? Maybe you could add that?

[musicinmybrain]

Awesome! The less dependencies the better.

What do you think is missing with regard to test coverage? Maybe you could add that?

I’m just not really confident that the coverage of various stages of the SparseRange is thorough enough to cover any subtle mistakes here, which is why I say I’m mostly relying on a careful reading of the relevant documentation. I’m not sure how the coverage could be very straightforwardly improved.

For example, if I incorrectly write < instead of <= in let right_index = self.left.partition_point(|x| x <= &(range_end + 1)); on line 58, the tests still pass. (If I make the same intentional error on line 100 instead, I do get a test failure.) But what test case should I add to cover that error? I guess with some careful analysis, and after developing a better global understanding of the code, I could derive a state in which that particular error causes the wrong outcome. But what about the kinds of errors I haven’t thought of?

This is the kind of situation where some people would reach for property-based testing, like Python’s hypothesis, but there doesn’t seem to be an actively-maintained crate for that in the Rust ecosystem at the moment.

[baszalmstra]

https://crates.io/crates/proptest seems pretty well maintained