It's used as a superclass for anonymous classes for adapted function
references. Its main feature is that it _doesn't_ inherit from KFunction
(as opposed to FunctionReference), as per the decision to postpone
reflection support for adapted function references in KT-36024.
#KT-36024 Fixed
Function references are now equal if they refer to the same function,
and if the parameter/return type adaptation, which happens when a
reference is used where some function type is expected, is exactly the
same. This includes the number of expected positional parameters (which
can be affected by defaults/varargs), whether the coercion of vararg
parameter to Array type happened, and whether the coercion of return
type to Unit happened.
#KT-37543 Fixed
Instead of generating overrides for getOwner/getName/getSignature in
each anonymous class representing a callable reference, pass them to the
superclass' constructor and store as fields. This occupies some small
memory but helps to reduce the size of the generated class files, and
will be helpful for adding further runtime information to callable
references, such as information about implicit conversions this
reference has been subject to.
Represent owner as java.lang.Class + boolean instead of
KDeclarationContainer, so that the unnecessary wrapping Class->KClass
wouldn't happen before it's needed, and also to make sure all callable
references remain serializable.
Note that the argument type where the "is declaration container a class"
is passed is int instead of boolean. The plan is to pass the
aforementioned implicit conversion information as bits of this same
integer value.
#KT-27362 Fixed
Instead of non-existing `kotlin.KotlinPackage`, which led to
NoClassDefFoundError as soon as reflection tried to call getOwner on a
builtin callable reference, use a reference to a new physical class
`kotlin.jvm.internal.Intrinsics$Kotlin`. This will allow to support
KT-17151.
Note that for API version less than 1.4, this will still lead to
NoClassDefFoundError, but this is not worse than the current situation
where it happens anyway.
* It enables subtyping relationship for keys and elements, allowing type-safe and concise manipulations on the context when complex hierarchies of elements (e.g. implementors of ContinuationInterceptor) are present
* It unblocks possibility to implement suspendCancellableCoroutine in stdlib
* Implementing proper polymorphic get and minusKey in AbstractCoroutineContextElement is impossible because it will introduce source-incompatible change
* ContinuationInterceptor get and minusKey are adjusted in a completely backwards-compatible way
Mikhail Bogdanov