A search of the instance's class info is required for all casts to interface types. It should be possible to eliminate it in some cases by being clever. For example, group the methods in an interface vtable by the super-interfaces and let the resulting vtable point to the middle of the sub-interface vtable.
This reverts commit 2622c36. I ended up NOT needing to use moduleSuffix in GenLLVM, so reverting this to the way it was upstream may simplify future merges.
One fix was needed on finding the right symbol to output for java.lang.System; that part now works. However, we have to arrange for the System.sym to be loaded before the System.class in rt.jar; for new we set sun.boot.class.path in the Makefile. With these fixes, runtime.scala is separately compiled, however running it produces the wrong output. runscala bin/separate2.bc separate2 # works runscala bin/separate3.bc separate2 # compiles but output wrong!
This represents a somewhat more sophisticated understanding of symbols we are asked to compile in GenLLVM. I dump symbol information to different files depending on whether it's a class or a module class (object). Reading back in the classes works okay, although I'm still not able to read back objects correctly.
This method, previously defined in GenJVM, produces either "$" or "" depending on certain conditions of the Symbol argument. The same logic is needed in GenMSIL (and GenLLVM), so it was being copy/pasted. Even for JVM backend, in Erasure, we needed to access it as global.genJVM.moduleSuffix. Seems more reasonable to make it a method of Symbol. Ideally, this is a change which could be accepted upstream.
Because BoxesRuntime for LLVM is implemented in scala there is no true static and since JavaPlatform externalEquals method is named equals it resolved to an OverloadedSymbol between the external equals and object equals. Could have kept using equals and filter to get the right symbol but it was much simpler to just change the name. We also need to fix up the call type and load the BoxesRunTimeClass module.
Passing and returning structures in LLVM is bad for portability. As much as possible we want the IR to be target independent so we pass fat references as two separate arguments and return fat references by returning the object pointer and storing the result vtable in a pointer argument passed for that purpose.
Very broken with respect to companion objects (modules) but I can compile the class `a.scala` first, and then `b.scala` (without specifying `a`) and it will pick up `a` from `irfiles/a.sym`. cd docs/examples/llvm ../../../build/quick/bin/scalac -no-specialization -cp irfiles \ -d irfiles -target:llvm a.scala runtime.scala @ffi.sources ../../../build/quick/bin/scalac -no-specialization -cp irfiles \ -d irfiles -target:llvm b.scala runtime.scala @ffi.sources
However, for now it still tries (and fails) to read them as .class files.
PathResolver hard-coded `new JavaClassPath`. For LLVM, I'd like to substitute a subclass instead. This patch turns PathResolver into an abstract class, and references to it are replaced by JavaPathResolver. It would be helpful if this change could be adopted upstream. It is just a generalization, and contains no LLVM-specific functionality. I tested that the resulting compiler can compile itself.
This should make loading them easier (more Java-like).
Pickles of inner classes are not kept around, and are noted as MISSING when encountered. Unclear whether they will cause problems with reading. GenJVM also lightly instrumented to print out which pickles it encounters.