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
There are mainly two kind of changes:
- skipping 'componentX' calls for destructuring entries named _
- fixing local variable table for them
- skip entries for destructuring entries named _
- use $noName_<i> format for lambda parameters named _
#KT-3824 Fixed
#KT-2783 Fixed
For initialization of destructuring entries in loops use the same logic
as for common local destructuring
The behavior may change a little: variable start label in a table
becomes less precise (now it starts a little bit earlier than it become initialized),
but it can't be very important as the same logic works for common
destructuring
Dmitry Petrov