Jar's inputs can contain zipTrees in case of fat jars,
which can cause slow build
(Gradle unpacks them into temporary dir; that can be slow)
#KT-24956 fixed
Since the property is public, it can be invoked from outside,
possibly trough other properties.
This can lead to unwanted side effects: we can create taskBuildDirectory,
because some other task reads the property in parallel with 'clean' task
in current project.
That's exactly what happened when we referenced the property from
'GradleCompilerRunner#buildModulesInfo'.
#KT-24938 fixed
AndroidGradleOrderEnumerationHandler is defined in gradle.xml that doesn't depend on the Android plugin.
So we need to additionally check if the Android plugin is installed/enabled.
Split COROUTINE_SUSPENDED marker to expect and actual because Kotlin/JS backend
expects it to be property without getter.
Update EXPECTED_REACHABLE_NODES in JS test data.
#KT-24986 Fixed
Temporary workaround for bootstrapping.
Building the project with plugin version 1.2.60-dev-xxx
and deployVersion='1.3-SNAPSHOT' fails because Gradle
substitutes kotlin-stdlib dependency of kotlinCompilerClasspath
configuration with project dependency ':kotlin-stdlib'.
kotlinCompilerClasspath configuration is used to run the compiler,
which cannot be started with not yet built ':kotlin-stdlib'.
Before this change, kotlin.suspend was being loaded as having a common
function type instead of suspend function type.
With LV=1.3, we expect that suspend function types should have
new Continuation interface as a last type argument, while
kotlin.suspend is built with LV=1.2 and has old Continuation.
This change might be reverted once stdlib will be rebuilt with LV=1.3
NB: kotlin.suspend doesn't need to be intrinsified since it only returns
its parameter with checkcast to kotlinin.jvm.functions.Function1
(i.e., it doesn't refer the coroutines package)
#KT-24861 Fixed
The call to `createTopLevel` instead of `create` (which creates
serializers for outer classes properly, with correct type parameter
contexts) caused MetadataSerializer to write type parameter metadata
incorrectly. For example, in the following case:
class A<E> {
inner class B<T, E> { ... }
}
A's type parameter E would get id 0, and B's type parameters T and E
would get ids 0 and 1. This is a problem because ids are supposed to be
unique for each class including its outer classes, and deserializer,
decompiler and stub builder rely on this assumption.
JVM metadata is unaffected because `create` is called correctly there,
see MemberCodegen#generateKotlinClassMetadataAnnotation
#KT-24944 Fixed
xiexed