Consider using ClassLoaderCache in Scala's integration

[jvican]

/cc @stuhood
When I was having a look at the Scala Zinc integration, I've noticed that you don't use the ClassLoaderCache when instantiating Scala's incremental compiler:

  def newScalaCompiler(instance: XScalaInstance, interfaceJar: File): AnalyzingCompiler =
    new AnalyzingCompiler(
      instance,
      CompilerBridgeProvider.constant(interfaceJar, instance),
      ClasspathOptionsUtil.auto,
      _ => (), None
    )

instead of what our default Zinc utils do:

  def scalaCompiler(
      scalaInstance: xsbti.compile.ScalaInstance,
      compilerBridgeJar: File,
      classpathOptions: ClasspathOptions
  ): AnalyzingCompiler = {
    val bridgeProvider = constantBridgeProvider(scalaInstance, compilerBridgeJar)
    val emptyHandler = (_: Seq[String]) => ()
    val loader = Some(new ClassLoaderCache(new URLClassLoader(Array())))
    new AnalyzingCompiler(
      scalaInstance,
      bridgeProvider,
      classpathOptions,
      emptyHandler,
      loader
    )
  }

Note the use of Some instead of None.

Using the classloader cache can provide great speedups, as evidenced by sbt/sbt#2754.

Is this an oversight or have you tried this option in the past and didn't happen to improve performance for Pants?

[stuhood]

Will give it a shot. Relates to #4477

[stuhood]

@jvican : Is it still useful entirely within one run? Or is it supposed to be used across multiple AnalyzingCompiler instances?

[jvican]

This is supposed to be used across multiple AnalyzingCompiler instances. I think it's under that scenario where performance improves considerably.