Other facades (JVM, Common, Native) are already created with such flag.
This should stop some known 'rewrite at slice'-exceptions from being
thrown (KT-21405, KT-29705).
For a more thorough investivation and details, refer to KT-30031.
Also, see KT-30030: even though it was fixed by the different commit,
the same scenario probably can be used to investigate other rewrites
(even though they will reproduce much less frequently than original
issue)
^KT-21405 Fixed
^KT-29705 Fixed
There is no Java support in CIDR. Therefore:
- analyze KTS in CIDR using Common platform
- disable error highlighting for KTS in CIDR
Issue #KT-29953 Fixed
- Drop unnecessary bunch files for `KotlinFacetType` and `KotlinFacetTypeImpl`
- Use cached val `isRunningInCidrIde` to check if the code is running under CIDR
Decide on completion order by other factors
Previously would prefer callable that return Unit if Unit is the expected type
leading to strange completion order
#KT-25588 Fixed
After the previous change, when being applied to a function type
with receiver it's assumed to work just as it's applied to receiver type
Thus, it's necessary to fix relevant IDE features relied on DSL markers
#KT-23255 Fixed
Main targets for the fix is completion, parameters info, inlay hints and
override/implement.
Other IDE functions might be affected.
#KT-24911 Fixed
#KT-25616 Fixed
#KT-25622 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
Optimize imports to classes when there's an import of a type alias to
that class with the same name. This results in "java.lang.*" imports
being optimized in favor of the corresponding type aliases in "kotlin.*"
which are imported by default
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)
There is a single PartialBodyResolveFilter instance per module
and each of them were containing just the same sets of available
in project Nothing-typed functions (including duplicating String instances),
in case of Kotlin project it might sum up to 27M of heap.
The solution is to share the global sets between all modules in a project
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Dmitry Savvinov