In Gradle < 4.7, there's no `ComponentWithCoordinates` interface, and we
need to make sure that none of our classes implementing this interface
are loaded with older Gradle versions.
Instead of that interface, we can rely on Gradle's metadata generation
heuristic that takes Maven coordinates for the variants from the
corresponding publications.
Note that this change brings an incompatibility: `Array<Foo>::class`
will be seen as `Foo::class` by the old deserializer. We consider this
OK because the compiler never had any logic that relied on reading class
literal arguments correctly (otherwise it wouldn't have worked because
it could only see `Array<*>::class` before this commit), and the support
of annotations on types in JVM reflection is only available in the
upcoming 1.3 release (KT-16795)
#KT-22069 Fixed
In new MPP, add source sets taking part in more than one compilation to
the tasks' `commonSourceSet` in order to pass them as -Xcommon-sources
Issue #KT-26515 Fixed
* Some of the usages of `kotlinSourceSets` should instead get all the
source set from the source set hierarchies, i.e. including the ones
transitively-participating in the compilation
After all MPP related changes, the `KotlinSourceSet` interface turns out
compatible with the old `KotlinSourceSet`, and, since there are external
usages of `KotlinSourceSet`, it is reasonable to expose the new
interface under the old FQ-name to fix those external usages.
Issue #KT-26498 Fixed
An incomplete list of inner class files might be stored in versioned
directory and that ruins Kotlin stub building.
Another reason for excluding such files, that they are duplicated
in different declarations lists such as `Navigate -> Class...` action.
#KT-26439 Fixed
java plugin makes idea import dependencies on this project as source (with empty sources however), this prevents reindexing of kotlin-compiler.jar after build on every change in compiler modules
Before this commit, without existing directory
we tried to create it only inside Java source roots,
which is incorrect for JS and other non-JVM modules.
Source roots themselves still aren't created if they don't exist.
This fixes KT-19586 partially
Before this commit, class super-type could be sealed only in the case
it's the class we are inside or in the same file with.
However, it's quite possible for the expect sealed class
to be implemented by typealias.
So in this commit we allow class super-type to be sealed
if it's typealias expansion we are inside.
Sergey Igushkin