Work-around optimiser deficiencies in Range iterator.

[oli-obk]

closes #24705

the issue in the other PR was that the inclusive range iterator depended on internals of the normal range iterator

range_inclusive (https://github.com/rust-lang/rust/blob/master/src/libcore/iter.rs#L2799-2808) won't work anymore due to the self.range.start == self.range.end check. This will cause https://github.com/rust-lang/rust/blob/master/src/librustc/middle/check_match.rs#L605 to produce 0 elements for range_inclusive(0, 0)

which then causes the match arm reachability to fail

This was not detected by the test-suite, because the failure happens during stage1 compilation of the standard libraries.

r? @aturon
cc @huonw @pythonesque @pnkfelix

[alexcrichton]

Unfortunately I think doing this addition outside the guard causes the panic semantics of this iterator to change, which I believe will be a regression. For example this code does not panic today, but I suspect it will panic with this implementation:

fn main() {
    for i in 255u8..255 {
        println!("{}", i);
    }
}

[oli-obk]

Yea, didn't notice that corner case...
Anyway, closing is perfectly alright with me, I just wanted to move the PR forward :)

[alexcrichton]

Hm ok, I think for now we may want to not merge this due to that, but perhaps we can think of a new idea in the future!

[alexcrichton]

Closing because I think this may be backwards incompatible