The intention of this code was to use the name "kotlin" for the builtins
module, in case we're using builtins loaded from the compiler class
loader (whose module is created in
`KotlinBuiltIns.createBuiltInsModule`). However,
`getBuiltIns().getBuiltInsModule()` may refer not necessarily to the
builtins module, but also to any valid module where the builtins are
visible from, therefore its name would be computed incorrectly. Use the
module name instead to determine if it's a synthetic builtins module
created in `createBuiltInsModule`
Use KotlinBuiltIns.isString instead of equality with
KotlinBuiltIns.string, which is more portable across different module
configurations. Also use isSubtypeOf instead of
DescriptorUtils.isSubclass and thus get rid of an extra error on an
unresolved class in nativeAnnotationCheckers.kt
The kotlin-native-shared artifact includes API allowing
us to work with K/N platforms, hosts, distribution etc.
This patch replaces a dependency on kotlin-native-utils
containing copies of such classes with a dependency on
published kotlin-native-shared in the Gradle plugin and
bundles kotlin-native-shared into the Gradle plugin jar.
so warning is not shown when discovery configuration is not populated
fix #KT-31124
refactor code for clarity on the way
also apply scripting subplugin after main plugin to ensure that
configurations are created before scripting is initialized
As Gradle may under certain conditions reorder the buildscript
classpath artifacts, we need to ensure that the `kotlin-build-common`
module, which duplicates some of the classes that are shaded and packed
into `kotlin-compiler-embeddable`, does not call `com.intellij.*`
classes.
Replace the `com.intellij.*` utils that were called on the execution
path with our own implementations.
Issue #KT-31106 Fixed
During coroutines transformation, we analyse liveness of local variables
in order to decide whether we need to spill them or not.
This analysis contains hot method `useVar`, in which we previously
iterated over all variables in LVT. This is done, since these variables
are seen by debugger and we assume they are alice.
However, this variables can be generated by inliner. In this case, the
LVT's size in huge. I.e. we have loop in hot method.
By hoisting the liveness analysis of the LVT and combining its result
with result of usual liveness analysis, we achieve speed-up from 2m30s
down to 5s.
#KT-30603 Fixed