Fix executable jars

[BarkingBad]

Coming back with fixes for the compiler to produce runnable jars.

@som-snytt, you can play with the compiler now, for example, you can try these commands

$ bin/scalac -d hi.jar compiler/test-coursier/run/myfile.scala
$ bin/scala hi.jar
Hello
$ bin/scalac -d hi2.jar -Xmain-class run.myfile compiler/test-coursier/run/myfile.scala
$ bin/scala hi2.jar
Hello

Unfortunately, there is some hacking:

1. We have to manually write the MANIFEST file. Currently, to write to jars we create the custom object JarArchive which sets up a new file system for writing files, then we write to it directly both bytecode and tasty files. JDK gives an interface called JarOutputStream which is convenient to produce Jar files and takes care of the creation of the manifest file, but with our current approach, it's hard to determine the manifest properties. We would have to store these files temporarily somewhere else then write them all using JarOutputStream (scala 2 has this pipeline afaik).
2. The above hack forces us to find the MANIFEST file manually, because JDK assumes that the MANIFEST file should be the very first entry in the Jar file (https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/JarInputStream.java#L74). Interesting fact is that it only is required for reading jars using JarInputStream, when we try to run this jar using java -jar ... it would start normally, even though MANIFEST is at the end of the archive.

Thigs to reconsider:

• attaching classpath to MANIFEST (or at least scala stdlib) so user can run it from java -jar ... command (running from bin/scala provides stdlib by default, so it is not problem for most of the simple scripts).

[BarkingBad]

This is copied from compiler/src/dotty/tools/dotc/sbt/ExtractAPI.scala I was thinking whether we could extract it for reuse rather than copy-paste, yet I wasn't sure where should I place it, maybe somewhere under dotty.tools.dotc.util

[smarter]

Please feel free to extract any code for reuse yes, doesn't matter too much where it ends up :). However, having to fully traverse every single compilation unit just to get main method names out is going to be fairly expensive and should be avoided, especially for information that we should already know. Maybe ExtractAPI (or some other phase which is always run if we want this to work even outside of sbt) should collect this information and store it in the Context. In fact, we used to have a phase which was supposed to do that but I deleted it because it was dead code: 3ebf919

[BarkingBad]

Thanks for the advice, I will look into that :D

[BarkingBad]

I recommend using an immutable collection, otherwise one needs to be very careful about not reusing the same EntryPoints instance in multiple contexts.

What is the correct way to update such context then or to pass fresh-cloned context with the updated state to the next phases?

[smarter]

You can use updateStore to replace the value of a Location in the Context. But if you move CollectEntryPoints to be just before the backend and only used by it, then you could also put the state in GenBCode like CollectSuperCalls does: https://github.com/lampepfl/dotty/blob/38b983c1b4a61d4c45f314ae895b95317c322c62/compiler/src/dotty/tools/backend/jvm/CollectSuperCalls.scala#L38

[BarkingBad]

I've seen updateStore, but it's only for FreshContext and I didn't dare to type check/cast the context and then invoke the updating function. The second solution like the CollectSuperCalls seems OK, though I just fixed myself on putting that into the context as you proposed earlier. Will change

[BarkingBad]

@smarter could you take a final look and give approve if everything is OK :)

[smarter]

Looks like this should be removed along with any code related to sbt in this phase since it no longer occurs before ExtractAPI.

[BarkingBad]

Fixed