If the compiler is invoked through JPS, an instance of
XmlMessageRenderer is used and the output should be a valid XML.
Previously, we reported the argument parse error (and the note to try
"-help") before calling messageRenderer.renderPreamble, which resulted
in invalid XML. The same was happening for the usage printed on "-help".
Both of these problems are fixed
#KT-14848 Fixed
This fixes the warning "The '-d' option with a directory destination
is ignored because '-module' is specified", when a project imported
from Gradle is built with JPS.
#KT-17665 fixed
Write the modular JDK (9+) path to the module.xml file passed to the
compiler from the JPS plugin. This path is then recorded in the compiler
configuration in KotlinToJVMBytecodeCompiler.configureSourceRoots. This
is needed because in JPS plugin, we pass "-no-jdk" and thus no JDK home
path was recorded in the compiler configuration in
K2JVMCompiler.setupJdkClasspathRoots. Presence of JDK home path in the
configuration is crucial for JDK 9 support (see
KotlinCoreEnvironment.Companion.createApplicationEnvironment), because
classes there can only be loaded with the special "jrt" file system, not
as .class files in .jar files
#KT-17801 Fixed
1. Determine source element for descriptors with NO_SOURCE recursively.
2. Always provide type abbreviation for type alias constructor
return type.
#KT-15495 Fixed
Previous test had an inline setter that didn't produce any effect,
thus, corresponding code was removed by new DCE.
Make sure that changes made in the inline property are caught up by IC.
Friend modules should be provided using the -Xfriend-modules flag
in the same format as -libraries. No manual configuration required for
JPS, Gradle and Maven plugins.
Friend modules could be switched off using the -Xfriend-modules-disabled
flag. Doing that will
* prevent internal declarations from being exported,
* values provided by -Xfriend-modules ignored,
* raise a compilation error on attemps to use internal declarations from other modules
Fixes #KT-15135 and #KT-16568.
findClass(String, GlobalSearchScope) is invoked for example when we're
resolving supertypes of classes in Java libraries. Previously, it never
found nested classes and falled back to CoreJavaFileManager's
implementation, which lacks a fix for the original issue (KT-12664,
which was fixed in JvmDependenciesIndex in 5a533a52 and 164c72e8)
#KT-16931 Fixed
Otherwise it breaks JPS assumptions, that leads to exceptions like:
Error:Kotlin: [Internal Error] java.lang.AssertionError: Couldn't load KotlinClass from /Users/jetbrains/IdeaProjects/KotlinPlaygroundBeta11/out/production/KotlinPlaygroundBeta11/Counter$both$1.class; it may happen because class doesn't have valid Kotlin annotations
at org.jetbrains.kotlin.build.GeneratedJvmClass.<init>(generatedFiles.kt:36)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.getGeneratedFiles(KotlinBuilder.kt:469)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.doBuild(KotlinBuilder.kt:241)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.build(KotlinBuilder.kt:140)
...
This is needed because SourceNavigationHelper uses default platform and it
needs default imports to be able to resolve references (otherwise
NavigateToLibrarySourceTestGenerated breaks)
Private-in-file declarations conflict with public overload-equivalent declarations
in other files in the same package.
Move functions for grouping possible redeclarations to OverloadResolver
(since they are used only there).
Refactor redeclarations / conflicting overloads reporting.
Mikhail Zarechenskiy