When 'languageVersion' isn't passed explicitly, compiler will choose
'LATEST_STABLE'.
This may lead to spurious migration of a project to the next major
version after plugin update (e.g. when user had project of major
version X and then installed plugin of version X+1 -- in such case,
meaning of "no language version" suddenly changes).
So, we set it to RELEASED_VERSION, which is exactly the version
that is safe to use as the fallback.
Original commit: b23bf371cf
There are few more such places. Better fix would be to avoid
situation, when we need to fallback. So in every project these
settings are defined. It means "Latest stable" setting is not good.
#KT-26364 Fixed
Original commit: 69a0fedd9f
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
Yan Zhulanow