- 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
for type safety, to easier distinguish between:
* short names
* qualified names
* jvm names (slash-separated)
* special names like <root>
* null values that mean "undefined" and "root ns" in different contexts
KT-1474 Execption when running kotlin project
KT-1501 Run script doesn't work in IDEA
In seems that to fix the problem completely, we need to avoid importing Java's default package into every file, but the problems reported in these requests are gone now.
#KT-1501 Fixed
#KT-1474 Fixed
Alex Tkachman