gaps return empty ranges

[gzp79]

version = "1.0.1"

Gaps returns empty ranges for this simple case:

let mut ss = RangeInclusiveMap::new();
ss.insert(0u32..=0u32, 0u32);
ss.insert(1u32..=1u32, 1u32);

for v in ss.iter() {
    log::error!("in {:?}", v)
}

for v in ss.gaps(&(0u32..=u32::MAX)) {
    log::error!("gap {:?} empty: {}", v, v.is_empty())
}

output:

[2022-04-14T09:27:26Z ERROR shine_crde::operations] in (0..=0, 0)
[2022-04-14T09:27:26Z ERROR shine_crde::operations] in (1..=1, 1)
[2022-04-14T09:27:26Z ERROR shine_crde::operations] gap 1..=0 empty: true             <---- I'd not expect this response
[2022-04-14T09:27:26Z ERROR shine_crde::operations] gap 2..=4294967295 empty: false

[gzp79]

In the form of a mini test:

#[test]
fn gaps_bug() {
    let mut ss = rangemap::RangeInclusiveMap::new();
    ss.insert(0u32..=0u32, 0u32);
    ss.insert(1u32..=1u32, 1u32);

    let mut gaps = ss.gaps(&(0u32..=u32::MAX));

    // bug, should not be here, see https://github.com/jeffparsons/rangemap/issues/43
    assert_eq!(gaps.next(), Some(1u32..=0u32));   
    
    assert_eq!(gaps.next(), Some(2u32..=u32::MAX));
    assert_eq!(gaps.next(), None);
}

[jeffparsons]

Thanks for the report, @gzp-crey. I will get on to this, but a bit pressed for time right now and working on sprucing up the test suite first to make sure that this sort of thing can't sneak in in future. (Watch this space.)

[jeffparsons]

@gzp-crey This is fixed in v1.0.2. (Just pushed to crates.io.)