Creation of KotlinTargetsIndex takes too long,
even if Java project doesn't have any Kotlin files.
Remove function hasJsStdLib, as it takes too much time
because of recursively checking all dependencies (migrate to facets)
Also fix tests: Add Kotlin JS facet, where its needed
#KT-34351 Fixed
Finding type alias doesn't work if it's not top level because the class
ID doesn't match. There doesn't seem to be a easy way to make it work
so this commit simply makes the IDE tolerate it.
This is causing issues such as https://issuetracker.google.com/183423660.
Annotation processor options that are provided by the Android Gradle plugin
may contain references to files and file collections that are safe to
evaluate only at execution time. This change avoids eagerly creating
compiler plugin options for these options, as they are already a task input.
Test: AbstractKotlinAndroidGradleTests.testAgpNestedArgsNotEvaluatedDuringConfiguration
^KT-39715 In Progress
This will prioritize classifiers from the following sources
in the provided order
1) Classifiers from the target's modulesProvider
2) Classifiers from the traget's direct dependencies
3) Classifiers from the more common dependencies
In a Gradle process, the user.dir property is set to the directory
where the build was started. By default, if we start a child process
via project.javaexec, Gradle sets its working directory to the
directory of the current project. But passing Gradle's value of user.dir
to that process overrides this setting.
This makes tools started in a such way sensitive to directory the build
is started from.
This patch fixes this issue for K/N-related tools started
out-of-process by the MPP Gradle plugin. But this issue is still
relevant to in-process tool execution.
In a Gradle process, the user.dir property is set to the directory
where the build was started. By default, if we start a child process
via project.javaexec, Gradle sets its working directory to the
directory of the current project. But passing Gradle's value of user.dir
to that process overrides this setting.
This makes tools started in a such way sensitive to directory the build
is started from. Thus a test using relative paths may fail if it is
started from a wrong directory.
This patch fixes this issue for Kotlin/Native tests.
Nikolay Krasko