rename source-sections compiler plugin jar in the dist (add kotlin- prefix),
according to the agreed naming scheme for the artefacts. (The renaming of the
other plugins should follow.)
in addition configure proguard to retain VirtualFile members, since they
are used in the source-sections plugin
Introduce system property kotlin.compiler.X.enable.idea.logger=true
The reason is that I suspect that the error is somewhere at com.intellij.ide.plugins.PluginManagerCore#loadDescriptorFromJar but unfortunately default logger doesn't log messages at "info" log level so we can't see why exactly does it fail.
Users can enable IDEA's logger to see more details.
Instead of reusing the same AnalyzerFacade that is used for resolution
of a module to resolve its dependencies, analyze each dependency
module/library with a facade depending on its target platform. Introduce
and use CommonLibraryDetectionUtil in addition to
KotlinJavaScriptLibraryDetectionUtil, to detect common libraries (with
.kotlin_metadata files).
Note that before multi-platform projects, this was not needed because
there were only two platforms (JVM and JS), and JVM module had only JVM
modules/libraries as dependencies, JS module had only JS
modules/libraries as dependencies. Now, for example, a JVM module can
have a common module/library as a dependency, and it would be incorrect
to analyze that dependency with JvmAnalyzerFacade because that facade
does not know anything about .kotlin_metadata files.
The changes in Dsl.kt and KotlinCacheServiceImpl.kt are needed because
PsiElement.getJavaDescriptorResolver, called from some IDE code, started
to fail on a common module, because the container for a common module
does not have the JavaDescriptorResolver
Recently the CompilerMessageLocation.NO_LOCATION was replaced with a null value.
This caused daemon clients to report "Unexpected message" for compiler messages without location.
Added resolving the compiler jar using the class loader urls as the
first step with the fallback to the original resolution method. Also
helps if the compiler is not present in the classpath dependencies.
Issues: #KT-16580 Fixed
Changed to getting plugin version from the applied plugin instead of
the plugin JAR name.
Removed unnecessary working with version of AbstractKotlinPlugin.
Added reverting processor path back.
Appending processor path instead of setting it.
Issues: #KT-17255 Fixed
(cherry picked from commit 843844b)
Added a test checking that -processorpath is set for all Gradle versions
Ilya Gorbunov