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)
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
23 invokes in KFunctionFromReferenceImpl (and consequently, in FunctionImpl)
were needed before 1576160390: a wrapped function
reference must have had the necessary invoke to be called as an instance of a
specific function type. After 1576160390, this is
not needed anymore because KFunctionFromReferenceImpl is now an internal
implementation detail of reflection, and no invoke is ever called on it.
They are overridden in all subclasses anyway: either in the corresponding
(Mutable)PropertyReferenceNImpl class, or in the anonymous class for a
reference, generated by the compiler.
Both primitive int and wrapper type java.lang.Integer are represented by the
single type kotlin.Int in Kotlin, so inequality between the corresponding
KClasses was confusing here. To keep the old behavior, one may call 'k1.java ==
k2.java' instead of `k1 == k2`
#KT-13462 Fixed
`java` in the package name inside an extension to KClass is now resolved to the
extension property `KClass#java`. So `java.X::class` is now equivalent to
`this.java.X::class`
Instead of relying on a class from the runtime (which thus cannot be deleted
from the runtime ever), rely on a class from the compiler instead. This has a
minor downside: that class is compiled by the bootstrap compiler, so if codegen
of 'for'-loops or something else used in that class changes, it won't
immediately have an effect on a local working copy (on the build server
everything will be fine because of a 2-step building process).
In the future it may make sense to just manually create all the bytecode
instructions and dump them into a MethodNode. Currently the amount of work
needed for that seems rather significant
To make them inaccessible from Kotlin sources and drop them later. They're
still needed in runtime because Kotlin tests run old IDEA code (which depends
on PropertyMetadata) with our own runtime
Dmitry Petrov