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
To compute modules to be added to compilation roots in
JavaModuleGraph.getAllDependencies, we should look not only for
transitive requirements of root modules, but for transitive requirements
of _root modules' requirements_. The same logic applies to
JavaModuleGraph.reads. In other words, when looking for a path in the
module graph between two modules, the first edge's transitiveness
doesn't matter, but all other edges after the first must be transitive.
There was also a stupid bug in dfs in
JavaModuleGraph.getAllDependencies: we continued the DFS only if the
module _was not_ added to the "visited" set ("add" returns true if the
element was added successfully)
#KT-18598 In Progress
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
Previously we assumed that a symbol is accessible if its containing
package is exported by module-info.java. Which was obviously wrong and
could lead to a situation where a symbol would be incorrectly accessible
if a usage module has a dependency on the symbol's module in IDEA
project terms, but does not require it in its module-info.java
#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
Before this change, diagnostic tests with Java source files failed
because KotlinCoreEnvironment was being created in the test's setUp,
even before the test data file has been split into .java/.kt and the
resulting .java files have been copied to a temporary directory. In
KotlinCoreEnvironment's constructor, we now inspect all roots for
module-info files, which involves calling VirtualFile.getChildren on all
roots in the configuration. CoreLocalVirtualFile.getChildren is
cached on the first access, and so because the temporary directory with
.java files was empty at this point, the VirtualFile for that directory
returned empty array in getChildren later in the test, resulting in
unresolved reference errors.
This is fixed by creating the environment _after_ the .java files have
been copied to a temporary directory. Note that slow assertions for
flexible types are now enabled in KtUsefulTestCase instead of
KotlinTestWithEnvironmentManagement, because BaseDiagnosticsTest no
longer inherits from the latter
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
Binding context and diagnostic structures are not thread-safe now and
need to be protected with the lock.
Fix flacky test testRemoveDuplicateImport
This also probably fixes some traces in EA-79696
As they remain in inline functions now proguard emits
a warning about them, even though inline suspend functions
are effectively inline-only and these markers can't be
executed at runtime
#KT-18702 Fixed
Before computing the FqName, check the simple class name first. This
code was responsible for about 20% of FqNameUnsafe instances created
during compilation of "core" modules
Reuse StringBuilder instances for nested subexpressions.
(NB StringBuilder instance for string template with a string
concatenation inside an expression entry, such as `"${"a" + "b"}"`,
will not be reused, although that doesn't seem to be a real-life issue).
#KT-18558 Fixed Target versions 1.1.4
#KT-13682 Fixed Target versions 1.1.4
Join adjacent strings literals, escaped strings, and constant values
(in a language version that supports const val inlining).
Use StringBuilder#append(char) for single-character constants
(e.g., " " in "$a $b").
#KT-17280 Fixed Target versions 1.1.4
#KT-15235 Fixed Target versions 1.1.4
If for some reason during preliminary analysis in redundant null check
elimination we failed to determine a local variable type statically,
treat it as java.lang.Object.
This will disable some further optimizations using precise type
information (such as INSTANCEOF check elimination), but will not fail
with an exception anyway.
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
Denis Zharkov