In certain cases, it's impossible to determine which module owns a
particular file without knowing the analysis context. For instance,
the file might be a part of a physical module, and be also included into
a virtual ad-hoc module (to be analyzed in separate, e.g. a VCS diff).
The new API allows to pass a contextual module. Basically it means
"give me a module for this element, implying that we are now analyzing a
contextual module".
^KT-57559 Fixed
ATM unconditional `resolvedStatus` call in `modality` causes a
performance degradation in our completion tests
Since `resolvedStatus` is called to make sure that all the
status-transforming compiler plugins had finished their job, it doesn't
make sense to call `resolvedStatus` if there are no such compiler
plugins registered
N.B. After KT-56551 is fixed, this optimization might become obsolete
and can be removed if proved so
^KT-58587 Fixed
Review: https://jetbrains.team/p/kt/reviews/10136
This commit is important in scope of KT-57553. It makes the migration
more smooth.
Other related tests:
- testUninitializedOrReassignedVariables
- testAugmentedAssignmentInInitializer
'forceSkipResolvedClasses' is wrong here, because nested class (`CC`)
won't be marked as cycle but the outer is.
Instead of this, we should check
canHaveLoopInSupertypesHierarchy recursively
```kotlin
open class C : <!CYCLIC_INHERITANCE_HIERARCHY!>D<!>() {
open class CC
}
open class D : <!CYCLIC_INHERITANCE_HIERARCHY!>C.CC<!>()
```
Also, this commit adds an optimization to avoid hierarchy search
for non-source classes (forceSkipResolvedClasses was introduced for this before)
JavaClassUseSiteMemberScope won't return a Java method getFoo if there
is an inherited Kotlin property foo in scope because calling this method
would effectively call the property accessor which is not possible in
Kotlin.
This commit excludes private properties from this consideration because
no accessor methods are generated for them, and so calling a Java method
getFoo is ok.
#KT-58577 Fixed
Also, this change adds SinceKotlin and Java.Deprecated to this phase
It fixes some problems with API_NOT_AVAILABLE, so now it is closer to K1
^KT-57648 Fixed
^KT-55723 Fixed
Previously, when a candidate was found with an applicability that is
better than the current best applicability, all previous candidates were
thrown away. Now we keep them, unless the new applicability is
successful. If no successful candidates are found, we fully resolve all
the unsuccessful ones and select the ones with the least bad
applicability. This improves diagnostics for unresolved calls.
#KT-57844 Fixed
This will fix problems with declaration clash.
Otherwise, a designation path to the constructor of the second class
from the snippet
```
class A
class A
```
Will contain the first class instead of the second
Also, this is more performed than trying to find a segment of
a path by providers
^KT-58546 Fixed
Nikolay Lunyak