Compilation of top level functions/properties/typealiases results in a bunch of
different .kotlin_metadata files, so we need to store names of these files to
avoid scanning the file system in the compiler when loading code compiled by
K2MetadataCompiler.
For this, we reuse the PackageTable protobuf message, which is already used for
exactly the same purpose in the JVM back-end
Fixed KT-14939: use expected receiver type when generating receiver code in get/set methods for bound property references.
Otherwise we have VerifyError for bound receiver 'null' of type 'Nothing?', which is mapped to 'java.lang.Void'.
TODO: proper equality comparison for property accessors ('x::prop.getter', 'x::prop.setter').
While it's impossible to declare a property with protected field and public
getter we split these entities
- `_controller` field is used inside coroutines
- `controller` getter is used for accesing controller from noinline lambdas
(also it can be used to obtain controller from continuation by explicit cast)
This change is made under the assumption that some version of built-in
classes will always be available through `module.builtIns.getBuiltInClassByFqName`
The main benefit are class-files sizes for them
(not repeating the same declaration for each coroutine)
Also it helped to simplify coroutine codegen code a little
Note that controller/label field become non-volatile (see KT-14636)
#KT-14636 In Progress
In subsequent commits, a JVM module will be able to have up to two package
fragments for a given package FQ name. For example, for package "kotlin" in
kotlin-runtime.jar there will be a LazyJavaPackageFragment with binary
(Kotlin+Java) dependencies, and a BuiltInsPackageFragment for built-ins
metadata (which is loaded from kotlin/kotlin.kotlin_builtins)
The problem with BasicInterpreter is the following:
it creates BasicValue objects that should be replaced in favor of StrictBasicicValue
See commit message in 25c6ac1 for clarification
#KT-14447 Fixed
Mostly this commit replaces instances of original BasicValue from ASM
with ones of StrictBasicValue having strict equals implementation
Optimization issue was related to non-symmetric 'equals':
- NotNullBasicValue("java/lang/Object").equals(BasicValue("java/lang/Object")) == false
- BasicValue("java/lang/Object").equals(NotNullBasicValue("java/lang/Object")) == true
#KT-14242 Fixed
Equals/hashCode are meaningful for TypeConstructor instances (see
AbstractClassTypeConstructor.java) in contrast to ClassDescriptor where
equality is referential
The main reason currently is to avoid eager construction of
defaultContinuationSupertype long before it's needed, which could fail without
built-ins in the classpath
Denis Zharkov