Following the TODO in CallableReferencesResolutionUtils.kt, delete the
suspicious scope and use the new resolution process with the qualifier which
was obtained after the resolution of LHS. However, by default the tower
resolution algorithm also considers each qualifier as a class value as well,
which would be wrong here because resolution of LHS as a "value" happens
earlier in DoubleColonExpressionResolver and with slightly different rules. To
avoid that, do not mix in the "explicit receiver" scope tower processor when
creating processors for callable reference resolution.
Also delete unused functions and classes related to deleted scope, refactor
Scopes.kt
#KT-8596 Fixed
The main change is in
NewResolutionOldInference.ResolutionKind.CallableReference, where
createVariableProcessor creates a processor which no longer lists objects
#KT-12322 Fixed
A lot of additional work was required to support them:
- Suspension points are being identified by two markers
instead of one pointing to suspend function call
- Approach with replacing return type of suspend function does not work anymore.
So we decode suspension return type as an argument for begin marker
- It became necessary to perform variables liveness analysis
(see comment in org.jetbrains.kotlin.codegen.coroutines.CoroutineTransformerMethodVisitor.spillVariables)
Instead of performing signature change during transformation
it's convinient to make just when generating corresponding call,
for example there is no need to think about default parameters as they just work as is
See comment above replaceSuspensionFunctionViewWithRealDescriptor for clarification
Currently it only contains additional synthetic declarations for suspend-functions
E.g. `fun <V> await(f: CompletableFuture<V>): V` for `fun <V> await(f: CompletableFuture<V>, machine: Continuation<V>): Unit`
- isFunctionType -> change the only usage in TracingStrategyForInvoke to check
for exact function type
- isExtensionFunctionType -> change all usages to check for exact extension
function type because extension function types are uninheritable in Kotlin
- isExactFunctionType -> isNonExtensionFunctionType
- isExactExtensionFunctionType -> isExtensionFunctionType
- isExactFunctionOrExtensionFunctionType -> isFunctionType
- isFunctionOrExtensionFunctionType -> isFunctionTypeOrSubtype
Mikhail Glukhikh