Now we will try to avoid redundant calculation:
* Class-like declarations can be calculated without super types
* Overridden search logic not is out of lock
Unfortunately, right now it is not safe to use
StatusResolveMode.FunctionWithSpecificName and
StatusResolveMode.PropertyWithSpecificName
because lazyResolveToPhaseWithCallableMembers can lead to an incorrect
state of scope. Example:
```
open class A {
open fun a() {}
open fun b() {}
}
class C : A()
```
Steps:
1. Resolve constructor of C to STATUS
2. Now we want to call lazyResolveToPhaseWithCallableMembers on
C, and this call will do nothing because this class and all
its declarations (only constructor) are already in STATUS phase,
so class A won't be resolved as expected
^KT-56551
The problem was that type parameters of Java function were changed
without any synchronization.
In fact, we shouldn't mutate Java declarations at all.
So now we don't mutate type parameters – instead of this,
we mutate only its copy that is safe
^KT-58613 Fixed
^KTIJ-25242 Fixed
^KTIJ-21791 Fixed
The key 'localDeclarationsData' is a IrFunction whose symbol owner is 'IrDeclarationOrigin.LOCAL_FUNCTION'. To find the 'localsData', it's required to get the original local IrFunction ('IrDeclarationOrigin.LOCAL_FUNCTION') for the IrFunction with default arguments (IrDeclarationOrigin.FUNCTION_FOR_DEFAULT_PARAMETER).
Related to KTIJ-25558
Single-letter names were very confusing, especially in declarations like
```kotlin
private inline fun <
reified D : IrDeclaration,
reified ES : IrDelegatingSymbol<AS, D, *>,
reified AS : IrBindableSymbol<*, D>
> finalizeExpectActual(
expectSymbol: ES,
actualSymbol: IrSymbol,
noinline actualizer: (e: D, a: D) -> Unit
)
```
It follows the 877438b1f3 commit removing LV/AV limits for the module and it needed to avoid, for example, cases when `i` is being uppercased to `İ` in the `TR` locale
When BI/incomplete call is present in return argument, it will be
added to the main call-tree, leading to requirement violation in
`ConstraintSystemCompleter.getOrderedAllTypeVariables`
as after `FirBuilderInferenceSession.inferPostponedVariables` it will
be completed, and its type variables couldn't be found anymore
In K1, we actually do the same, but we are able to find type variables
of such calls due to architecture difference:
In K2, `getOrderedAllTypeVariables` uses FIR as the main source to
lookup
In K1, `getOrderedAllTypeVariables` uses resolution atom tree, where
candidate/CS of the call is still available after
`inferPostponedVariables`
In fact, all incomplete calls were analyzed in FULL mode according to
the contract of `FirBuilderInferenceSession.addPartiallyResolvedCall`.
Thus, it means we normally shouldn't add them to the main call-tree, but
accidentally do it as incomplete calls contain non-completed candidate
This particular commit addresses the problem partially, only
in cases when the expected return type for the lambda is Unit and when
the incomplete call is located in the last expression of the lambda
In such cases, we can skip the call from the last expression completely,
since all potential calls there were analyzed in FULL mode,
and couldn't introduce any useful info to the CS of the main call-tree
^KT-54294
So, we're slowly getting rid of the hack with LATE_JDK_SIGNATURES
which is necessary because there's no freshest JDK available at
build agents.
But hope, it would be removed once JDK 21 is there (see KT-58716).
Alexander Udalov