SI-8815 mutable.LongMap makes different choices for splitAt vs etc.

It turns out that take/drop/splitAt/takeWhile/dropWhile inherit a smattering of foreach vs. iterator-based implementations.  These aren't consistent unless they iterate in the same order.  This probably reflects an undesirable underlying weakness, but in this particular case it was easy to make LongMap's foreach order agree with iterator.

Made traversal order of other foreach-like methods match also.

Also fixed a bug where Long.MinValue wasn't iterated.

Added unit test for iteration coverage of extreme values.

1 files changed, 15 insertions, 0 deletions

diff --git a/test/junit/scala/collection/SetMapConsistencyTest.scala b/test/junit/scala/collection/SetMapConsistencyTest.scala
index eed6007eef..261c11a98b 100644
--- a/test/junit/scala/collection/SetMapConsistencyTest.scala
+++ b/test/junit/scala/collection/SetMapConsistencyTest.scala
@@ -514,4 +514,19 @@ class SetMapConsistencyTest {
     assert( hs.toList.toSet == hs )
     assert( hs == hs.toList.toSet )
   }
+
+  @Test
+  def testSI8815() {
+    val lm = new scala.collection.mutable.LongMap[String]
+    lm += (Long.MinValue, "min")
+    lm += (-1, "neg-one")
+    lm += (0, "zero")
+    lm += (Long.MaxValue, "max")
+    var nit = 0
+    lm.iterator.foreach(_ => nit += 1)
+    var nfe = 0
+    lm.foreach(_ => nfe += 1)
+    assert(nit == 4)
+    assert(nfe == 4)
+  }
 }