inlining creates duplicates when anon-closure-class can't be eliminated after all

[scabug]

Sometimes it happens that"

• an anon-closure's apply() gets inlined (let's call that method A), but
• a sibling method invoked by A (ie also owned by A's owner) doesn't get inlined (that sibling method is usually an specialized apply).
  In general, whenever the instance of the anon-closure-class is used somehow.

As a result, the anon-closure-class can't be eliminated, and we end up emitting code duplicates (for the method/s that did get inlined). When compiling the compiling under -optimize about 600 anon-closure-classes are prone to this. In these cases it would be best not to inline at all.

Somewhat related,

• private members of anon-closure-classes that aren't used in their owning classes could be removed by DeadCodeElimination.
• more aggressively, any synthetic private member that can't be accessed from a non-private member could be removed (no statistics gathered yet on the eventual bytecode reduction).
• doing that for non-synthetic private members would go too far.

[scabug]

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

[scabug]

@magarciaEPFL said:
The following quick hack (visiting anon-closure-classes in a compilation unit before other classes) won't do the trick:

  class InliningPhase(prev: Phase) extends ICodePhase(prev) {
    def name = phaseName
    val inliner = new Inliner

    override def apply(unit: global.CompilationUnit) {
      val Pair(anonClos, nonAnonClos) = unit.icode partition { ic => isClosureClass(ic.symbol) }
      anonClos    foreach apply
      nonAnonClos foreach apply
    }

[SethTisue]

@lrytz should this stay open?

[lrytz]

let's track it here scala/scala-dev#53