Fix an exception when kotlin resolve was invoked when searching
for tests while indexing (probably many other cases)
Does not actually fix the behaviour, the test will not be found
resulting in undesired behaviour
Full-blown infrastructure for resolving Kotlin in dumb mode is needed
to fix the behaviour
#KT-24979 Fixed
Previously, PartialBodyResolveFilter didn't know about contracts and was
filtering out calls of such functions, leading to unstable completion in
cases like that:
fun test(x: Any?) {
require(x is String)
x.<caret>
}
However, PartialBodyResolveFilter works by pure PSI, while to determine
if function has a contract we have to resolve it.
To solve it, we do something very similar to what has been done with
Nothin-returning functions: introduce
KotlinProbablyContractedFunctionShortNameIndex, which collects all
function which *may* have a contract during indexing.
^KT-25275 Fixed
This is needed for further commit, which supports contracts-based
smartcasts in partial body resolve mode.
NB: Stubs can be built from 3 sources:
- source code (contract presence can be checked by PSI)
- binary data (contract presence can be checked by Kotlin Metadata)
- decompiled sources
The last case is a bit of a headache, because usually bodies are omitted
in decompiled sources. To workaround it, we have to inject stubbed
contract-call in the body.
Before this commit, we always tried to find expect property in this case.
However, there is at least one case when we should find parameter of
expect primary constructor instead (safe delete).
So #KT-25321 Fixed
It should help to avoid visiting children of each jar in java projects
LibraryEffectiveKindProviderImpl has it's own in-memory cache
but it doesn't help when project is reopened
#KT-25129 Fixed
#KT-25034 Fixed
Previously, packages `java.lang` and `kotlin.jvm` were imported on JVM
by default on the same rights, causing problems when the same classifier
existed both in `java.lang` and `kotlin.jvm`. Since the only known case
of such conflict were type aliases to JVM classes, the corresponding
classes (expansions of those type aliases) were manually excluded from
default imports. This made the code in DefaultImportProvider complicated
and resulted in multiple problems, regarding both correctness and
performance (see 82364ad3e5, a9f2f5c7d0, dd3dbda719).
This change adds a new concept, a "low priority import", and treats
`java.lang` as such. Since these imports are now separated from the rest
of default imports in LazyImportScope via secondaryClassImportResolver,
conflicts between classifiers are handled naturally: the one from
`kotlin.jvm` always wins (unless the one from `java.lang` is imported
explicitly, of course). This approach is simpler, safer and does not
require any memory to cache anything.
Skip ResolveToJava.kt test for javac-based resolve; it now fails because
of a weird issue which I didn't have time to investigate (this is OK
because it's a corner case of an experimental functionality)
Collect module name properly from facets settings, using CLI arguments
which define module name ('-module-name' on JVM and Common,
'-output-file' on JS).
^KT-23668 Fixed
Nikolay Krasko