Stabilise memberNames iteration order

[dwijnand]

Compiler version

3.1.0

Minimized example

A minimized example is hard because changes in code surrounding this internal implementation detail can disrupt it. But one way to reproduce it was in #13878 (comment).

class C { def x: Long = 123456789L.round }

Output

% ./dist/target/pack/bin/scalac -deprecation tests/neg-custom-args/deprecation/t3235-minimal.scala       
-- Deprecation Warning: tests/neg-custom-args/deprecation/t3235-minimal.scala:1:35 
1 |class C { def x: Long = 123456789L.round }
  |                        ^^^^^^^^^^^^^^^^
  |method round in class RichLong is deprecated since 2.11.0: this is an integer type; there is no reason to round it.  Perhaps you meant to call this on a floating-point value?
1 warning found
% ./dist/target/pack/bin/scalac -deprecation tests/neg-custom-args/deprecation/t3235-widen.scala
-- [E167] Lossy Conversion Warning: tests/neg-custom-args/deprecation/t3235-widen.scala:1:24 
1 |class C { def x: Long = 123456789L.round }
  |                        ^^^^^^^^^^
  |                   Widening conversion from Long to Float loses precision.
  |                   Write `.toFloat` instead.
1 warning found

Expectation

That is no longer reproducible with #13911. But you might be able to reproduce it by reverting that change.

The overall expectation is that the names of the input source files shouldn't change the behaviour of the compiler. More specifically it shouldn't vary the order in which memberNames are iterated (which is determined by the name hashes). I attempted to fix this in #13973, but ran out of steam. In addition to input source files, also the order in which names are forced affects the hashes of their (and the following) names in the names table, which means a change in forcing order can have a long distance effect in the compiler's behaviour.