Built-in classes like jet.Int and jet.Iterable are loaded from source
files by KotlinBuiltIns class. It makes no sense to create JetLightClass
instances for such classes, moreover, it causes runtime failures.
Now we check the location a file was loaded from before creating a light
class, and skip if it is a built-in.
We also assert this in teh actual generation of light class bodies, and
print out OS information if something fails, because our detection strategy
may depend on OS-specific behavior.
- generation method names standartized on genXXX
- many methods moved to newly created AsmUtil
- some methods moved to CodegenContext
- got rid of almost trivial StubCodegen
- PsiCodegenPredictor moved to binding package
- CodegenUtil.findSuperCall method moved to CodegenBinding
= PsiCodegenPredictor unneeded bindingTrace parameter replaced by bindingContext
If we allow JetLightClass to be created on built-in types, a normal codegen
would be launched, with a mapping from Kotlin to Java types enabled, every time
IDE requests built-in classes. Codegen would then try to make something
meaningless, e.g. create a class for a primitive type (since our jet.Boolean is
mapped to primitive boolean). This would result in different exceptions when
navigating to built-in library from IDE.
Add a helpful error message to ClassFileFactory if we ever again produce
classes for primitive types.
GenerationStrategy introduced to handle separately cases of regular compilation and building of JetLightClasses (this was only real overridable behavior of GenerationState in old code)
state subpackage introduced
In the most places in frontend identifier is stored in Name class, was in String.
Name has two advantages over String:
* validation: you cannot accidentally create identifier with dot, for example
* readability: if you see String, you don't now whether it is
identifier, fq name, jvm class name or something else
Name's disadvantage is (small) performance overhead. We have no value types in JVM.
Holds reference to runtime.jar and jdk-headers.jar. Paths to these
jars are no longer hardcoded.
Many tests now compile runtime before execution. Because of this:
* Single test invocation is significantly slower now for some tests
* This can be fixed by making tests independent from runtime (this
must be done anyway)
Some tests still depend on runtime.jar built by "ant dist", this
is to be fixed.
* cleanup after yesterday
* remove BindingContext stack in GenerationState
* use more power and strength of di
TODO: also initialize GenerationState by DI
Evgeny Gerashchenko