invalid change of parameter name for cloned symbol in build manager

[scabug]

I've already spent some time on this ticket, but I am creating it so that it doesn't get forgotten.
Code

class As {
  trait A {
      def foo(parents: String): A = {
        (() => parents)
        null
    }
  }
}

detects (wrongly) a change in definition of method foo (parents$$1 changed to parents). For some reason a cloned symbol of trait As$$A gets changed when we try to compile again with RefinedBuildManager even without making any changes to the source class.

In this case the for loop is the source of anonymous class and since parents is used in the body of for, therefore it gets renamed to parents$$1 in lambdalift, but the point is that this shouldn't affect the symbol that is cloned at the end of build manager process.

This is a reduced example of what I believe is happening for Types trait in symtab package. It causes (a very annoying) excessive compilation.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-3140?orig=1
Reporter: @hubertp

[scabug]

@hubertp said:
Another thing is that if outer class As is removed, or trait A becomes a class, then the problem disappears.

[scabug]

@lrytz said:
Here's a wild guess, but maybe it's related to lines 149-157 in !LambdaLift.scala [http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/compiler/scala/tools/nsc/transform/LambdaLift.scala#L149]

Lukas

[scabug]

@hubertp said:
Yes, that's very possible. Thanks for the pointer!

[scabug]

@lrytz said:
Replying to [comment:5 plocinic]:

Yes, that's very possible. Thanks for the pointer!

Note: Given an tree @ DefDef(..., vparamss, ...), you cannot generally assume that the symbols

vparamss map (_.map(_.symbol))

and

tree.tpe.paramss

are the same or have the same names. The same is true for type parameters, there it's actually implemented more systematically (using the infamous "skolems").

[scabug]

@hubertp said:
(In r24277) Closes #3140, #4245. no review