SI-8010 Fix regression in erasure double definition checks

Calls to `Symbol#info` during scope iteration considered harmful.

Looks like calling `info` during this Scope iteration is triggering
the ExplicitOuter info transformer, which "makes all super accessors
and modules in traits non-private, mangling their names.". This name
change necessitates a rehashing of the owning scope, which I suspect
is enough to corrupt the ScopeEntry-s being traversed in
`checkNoDeclaredDoubleDefs`.

The upshot was that we encountered the same symbol twice, which was
reported as being a double-definition.

This problem only showed up after 086702d8a74, which did nothing
worse then change the order in which `{e, e1}.sym.info` were
forced.

I inspected SymbolPairs/OverridingPairs which *appear* to be immune
as they only test flags during scope iteration; infos are not used
until later, at which point we're iterating a temporary scope that
isn't part of the type of the owner of the symbols.

1 files changed, 22 insertions, 0 deletions

diff --git a/test/files/run/t8010.scala b/test/files/run/t8010.scala
new file mode 100644
index 0000000000..8636bbd12e
--- /dev/null
+++ b/test/files/run/t8010.scala
@@ -0,0 +1,22 @@
+trait Base {
+  def t          = 1
+  def t(n: Int)  = n
+  def bt         = 2
+  def bt(n: Int) = n
+}
+trait Derived extends Base {
+  // was: double defintion error
+  override def t          = 1 + super.t
+  override def t(n: Int)  = 1 + super.t(n)
+  override def bt         = 1 + super.bt
+  override def bt(n: Int) = 1 + super.bt(n)
+}
+
+object Test extends App {
+  val d = new Derived {}
+  // not the focus of thie bug, but let's just check the runtime behaviour while we're here.
+  assert(d.t == 2)
+  assert(d.t(1) == 2)
+  assert(d.bt == 3)
+  assert(d.bt(1) == 2)
+}