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
NB in FE unsigned integer constants are now represented using signed
integer types (e.g., UInt constant actually holds an Int value).
So, in IR so far we also represent unsigned constant literals as
constant values of corresponding signed types, but with corresponding
unsigned type:
0xFFFF_FFFFu becomes 'CONST Int type=kotlin.UInt value=-1'
Nikolay Krasko