No package annotations are going to be loaded, and
TypeQualifierDefault/TypeQualifierNickname are no longer recognized by
default. Use the CLI argument "-Xload-jsr305-annotations" to enable this
behavior back
#KT-10942
If a path to the module-info.java file is passed as an argument, we
should treat all other source files passed as arguments (either as
individual source files or inside a source directory) as members of that
module. Previously we treated other source files as members of the
unnamed module, and this resulted in incorrect errors when using a
member exported with a qualification from another named module, for
example
#KT-18598 In Fixed
Note that javac reports a nice error in this case ("package foo is
declared in module lib, which is not in the module graph"), but we only
report "unresolved reference" because the corresponding modules are not
added to classpath roots. We should improve this in the future
#KT-18598 In Progress
Files like ant-javafx.jar, deploy.jar, java.jnlp.jar, javafx-swt.jar etc
should not be added to the classpath if JDK home points to a JDK 9
distribution
In this commit, only IDE tests are added, because we look for module
declarations in the IDE across the whole project, whereas in the
compiler we should do this on the module path only and that requires
separate work (KT-18599) which is done in the following commits.
(The change in Cache.kt is needed so that
JvmModuleAccessibilityChecker.ClassifierUsage, which is an inner class,
would be injected properly.)
#KT-18598 In Progress
#KT-18599 In Progress
Previously we traversed all notLoadedRoots on each request for package
parts with the given package FQ name. Since notLoadedRoots might contain
a lot of roots (which never transition into "loadedModules" because e.g.
they are not Kotlin libraries, but just Java libraries or SDK roots with
the META-INF directory), this was potentially hurting performance. It
seems it's more optimal to compute everything eagerly once
JvmPackagePartProvider is constructed.
Another problem with the previous version of JvmPackagePartProvider was
that it did not support "updateable classpath" which is used by REPL and
kapt2, it only used the initial roots provided in the
CompilerConfiguration. In REPL specifically, we would thus fail to
resolve top-level callables from libraries which were dynamically added
to the execution classpath (via some kind of a @DependsOn annotation).
In the new code, JvmPackagePartProvider no longer depends on
CompilerConfiguration to avoid this sort of confusion, but rather relies
on the object that constructed it (KotlinCoreEnvironment in this case)
to provide the correct roots. This is also beneficial because the
computation of actual VirtualFile-based roots from the ones in the
CompilerConfiguration might get trickier with modular Java 9 roots
No tests added because the only way to test this seems to be to launch a
new process and send "Ctrl+D" into it, which seems cumbersome for such
small change
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
Invalid compiler arguments should lead to a compilation error, not
internal error. This has been fixed by splitting the
"parseArguments(...)" call (which does parsing + validation) in
CompileServiceImpl into two calls of parseCommandLineArguments +
validateArguments, and returning with a compilation error if the latter
did not succeed
#KT-16057 Fixed
#KT-14848 In Progress
According to the spec, "java.se" and every other non-"java.*" module
that exports at least one package without qualification, is a root.
Currently we only support compilation of a single unnamed module, and
apparently unnamed module should read all root modules.
#KT-18180 Fixed
Alexander Udalov