Stop relying on scala.tools.nsc.MainGenericRunner

[smarter]

There are two places where we end up going through MainGenericRunner:

• ./bin/dotr calls scala which will call the runner
• partest run tests are run by it: https://github.com/scala/scala-partest/blob/v1.0.11/src/main/scala/scala/tools/partest/nest/Runner.scala#L181

MainGenericRunner will make up its own classloader then call the main method of the object using this classloader, this makes it considerably more complicated to figure out how the classpath stuff works (and it's already way too complicated). We should have our own runner.

[DarkDimius]

I'd prefer not to invent our own MainGenericRunner for only sake of not using the one coming from Scalac.

MainGenericRunner will make up its own classloader then call the main method of the object using this classloader,

This is needed to run partest test corrently, as they should run in different classloaders.

If we can simplify it, we better also simplify it for upstream scala/scala.
But, given the fact that it's already 90 lines of simple code, I don't see any problem with it being too complex.

I would definitely prefer not to replace it with something highly coupled with sbt.

[smarter]

This is needed to run partest test corrently, as they should run in different classloaders.

No, it's not needed, look at the code: https://github.com/scala/scala-partest/blob/v1.0.11/src/main/scala/scala/tools/partest/nest/Runner.scala#L181 we run java -classpath ... scala.tools.nsc.MainGenericRunner so we are already running the tests in a separate JVM with a separate classloader, but then we're using MainGenericRunner that will change our classloader and load our main class using reflection, this makes it impossible to properly restrict the classpath we use to run tests (needed to fix #1301).

But, given the fact that it's already 90 lines of simple code, I don't see any problem with it being too complex.

It's more than that. It will set up some stuff with GenericRunnerCommand, depending on what it detects, it will call ObjectRunner which will call ScalaClassLoader#run, or it will call ScriptRunner or JarRunner, etc.

I would definitely prefer not to replace it with something highly coupled with sbt.

I never said that. In fact, we shouldn't do that: the first example I showed where we depend on MainGenericRunner is ./bin/dotr which shouldn't depend on sbt. Currently it calls scala, this probably only works if you have scala 2.11 on your classpath, if you have 2.12 then you'll probably end up with the scala-library_2.12 on your classpath and weird things may happen. We should have a DottyGenericRunner class or something like it.

[felixmulder]

Yup, running tests in CI (#1322) will probably need to service this issue somewhat also.

[smarter]

Fixed a while ago.