resolve status of scala/scala#8466 for 2.12.11

[SethTisue]

scala/scala#8466 caused a community build failure in scalariform;
needs investigation before releasing 2.12.11

@lrytz @retronym @mkeskells

[SethTisue]

failure log: https://scala-ci.typesafe.com/job/scala-2.12.x-integrate-community-build/5532/artifact/logs/scalariform-build.log

could our be regression, but it could perhaps just be some wrong/fragile assumption in scalariform

the problem is reproducible outside of dbuild as follows:

hub clone scala-ide/scalariform
cd scalariform
sbt
set resolvers += "scala-integration" at "https://scala-ci.typesafe.com/artifactory/scala-integration/" ++2.12.11-bin-466f92f
scalariform/testOnly *MiscExpressionFormatterTest

[SethTisue]

if it does turn out to be a regression in HashMap, it's a bit alarming that scala/scala-collection-laws (which is part of the community build) didn't catch it — would be nice to add an appropriate law there once the nature of the problem is understood

[retronym]

Looks like a regression in merging HashMap-s that are distinct.

This:

That:

Comes together in:

mergeDistinct$1:802, HashMap$HashTrieMap
merge0:878, HashMap$HashTrieMap
merged:137, HashMap
$plus$plus:184, HashMap
$plus$plus:173, HashMap
mergeWith:45, FormatResult

Which computes:

The allBits bitmask looks wrong. In 2.12.10, the bitmap is -259938295:

I'll construct a unit test with the same Trie structure.

[SethTisue]

@Ichoran can I interest you in adding a law for this?

[retronym]

I think the reason it might have slipped through is that foreach and iterator (and the stack of generic operations built atop that) seems to work for HashTries with a corrupt bitmap. I think that's because TrieIterator doesn't use the bitmap, it just uses instanceOf-s to discriminate between data and sub-nodes in the elements array.

HashMap.equals is sensitive to the bitmaps, as is .get.