Fix parse error described in #35#36
Conversation
This change adds a `new` fn, which uses debug assertions to validate the arguments. It also uses the non_exhaustive attribute to ensure callers have to call new instead of initializing the struct directly, and updates all affected code paths to use the new function.
After handling an excluded range, the start variable is bumped to the end of the excluded range. This can cause it to be past the end of the next parent range. Previously, the implementation would push an invalid range when that happened. This change adds a condition to prevent that from happening.
|
I've pushed the rest of the changes into the pr/edition-2024 and pr/rewrite-intersect_ranges_impl branches on my fork. Here's a permalinked comparison. It's best reviewed as separate commits, to avoid having to filter out noise from I can submit these in 3 separate PRs, merge them all into one, or something in between, as needed. |
|
Updating to edition 2024 would raise the MSRV significantly and libraries should avoid doing that unless there's something we really need in a higher Rust version. |
I really enjoyed being able to use let chains, but it sounds like it probably wouldn't fall into your definition of need, and it bumps the required Rust version up to 1.88.0. Edit: I've backported my changes to the existing MSRV, and merged them into the branch for this PR. |
This allows the compiler to instantiate a single instance of the generic intersect_ranges_impl function, rather than monomorphizing a different version for each arm of the match.
The previous implementation had at least one other bug in it, but it was written in a way that was overly hard to reason about, and less idiomatic than it could be. Rather than try to incrementally fix bugs, it felt more efficient to rewrite it as a pair of iterator transformations, one to handle exclusion, and a second one to calculate the intersections. This version should result in similar compiler output, but with more readable source code, and a style of interface that's easier to compose with other iterator functions.
sruggier
changed the title
|
@the-mikedavis would you mind offering updated feedback about this, when you have time? |
2 participants
Here's a minimal fix for the problem documented in #35.
It looks like there are other potential problems with
intersect_range_impl, but addressing them fully is more complicated, and would be simpler if I could use let chains. That would require updating the edition to 2024, so I decided it would probably make sense to defer those changes into a separate PR or two.