Work-around optimiser deficiencies in Range iterator.

The conditional mutation of the previous implementation resulted in poor
code, making it unconditional makes `Range` less well behaved as an
Iterator (but still legal) but also makes it fast.

The intention is that this change will be reverted when rustc/LLVM
handle the best-behaved implementation better.

cc rust-lang#24660

Author: huonw

src/libcore/iter.rs

@@ -2896,9 +2896,17 @@ impl<A: Step + One> Iterator for ops::Range<A> where
 
     #[inline]
     fn next(&mut self) -> Option<A> {
-        if self.start < self.end {
-            let mut n = &self.start + &A::one();
-            mem::swap(&mut n, &mut self.start);
+        // FIXME #24660: this may start returning Some after returning
+        // None if the + overflows. This is OK per Iterator's
+        // definition, but it would be really nice for a core iterator
+        // like `x..y` to be as well behaved as
+        // possible. Unfortunately, for types like `i32`, LLVM
+        // mishandles the version that places the mutation inside the
+        // `if`: it seems to optimise the `Option<i32>` in a way that
+        // confuses it.
+        let mut n = &self.start + &A::one();
+        mem::swap(&mut n, &mut self.start);
+        if n < self.end {
             Some(n)
         } else {
             None

src/libcoretest/iter.rs

@@ -1167,3 +1167,10 @@ fn bench_max(b: &mut Bencher) {
         it.map(scatter).max()
     })
 }
+
+#[bench]
+fn bench_range_constant_fold(b: &mut Bencher) {
+    // this should be constant-folded to just '1000', and so this
+    // benchmark should run quickly...
+    b.iter(|| (0..1000).count())
+}