This will be useful to implement version-dependent deserialization,
which is needed for gradual fixes of issues in metadata
#KT-25120 In Progress
Original commit: 4122021090
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 d8e591f873, 930319281f, 5a048fea6b).
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)
Original commit: 1f0fb4823f
KotlinSourceRootType will added with KotlinSourceRootProvider (ex KotlinMppCommonSourceRootProvider).
New target type (with computeAllTargets) is not possible because ModuleBuildTarget is final.
#KT-24506 fixed
Original commit: 65bdfa72c1
- support common modules metadata compilation under flag (it is not required since all common source roots are included transitively for now)
- introduce expect actual tracker in jps: move implementation from gradle to build-common
- support js incremental compilation: move implementation from gradle to build-common
Original commit: 0eee2729cd
Use distJar configuration instead.
It's necessary because currently when using default-type, subproject
starts having a transitive dependency to :kotlin-stdlib-common
and that leads to exception from KT-20897 when building light classes
This change might be reverted once KT-23942 is fixed
#KT-23942 Submitted
Original commit: 003f381fcd
The test was failing recently on CI, but assertion message
does not give enough info: arrays' sizes are not equal,
so there were extra warnings, but what they were?
Original commit: adc3e61742
Creating and disposing CoreApplicationEnvironment on each call leads to
problems with parallel builds, while KotlinCoreEnvironment
avoids disposing application environment in case of parallel builds.
#KT-23694 fixed
Original commit: bd50ad87ba
Alexey Tsvetkov