It seems to be very natural refactoring considering the
following changes: optimizing KotlinCliJavaFileManagerImpl.findClass
to make it read class files manually instead of requesting PSI
The reason is that searching for a class in a VirtualFile-based
directory (i.e. in a package) happens for O(|amount-of-files-in-dir|),
and it may be rather crucial for packages with a huge amount
of classes
Note that it was checked that the cache should not take a lot of heap
since we call findClass only for really existing classes:
see org/jetbrains/kotlin/load/java/lazy/descriptors/LazyJavaPackageScope.kt:48
For example, there are no more than 10k classes for the whole
intelliJ project (but the cache is flushed for each module)
It's important because even if we know the root where
the package is located we need to go through its parts,
and it's not as fast as it could be since implementation
of VirtualFile.findChild() traverse all files in the directory
to find the relevant one
use it from the installed plugin for dependent modules (frontend)
use it from bootstrap in the plugin being built
also drop unused daemon-client from the plugin
This makes it consistent with ant build and allow building idea project
without prior ant dist
Also, remove kotlin-reflect form container module.
Main goal is get rid of kotlin-reflect.jar from modules what required for minimal compiler.jar which can compile Kotlin only to JS to make it smaller.
Use a single coroutinesState instead. Change the coroutines state in
some tests from "warn" to "enable"/"error" to test that deserialization
of older config files works ("warn" is the default value, so it wasn't
testing anything here)
The main reason of this change is that major changes are required in how
command line arguments are parsed in kotlinc, and it's much easier to
make them in our own codebase (given that the code is short and simple
enough) than in a third-party library
When Logger is not initialized it returns default logger which prints to stdout and stderr,
so it can lead to different results when run CLI tests locally and on TC.
As "java" does, do not include the current directory to the classpath if
the explicit classpath is specified. This is more stable than always
adding the current directory, and users can easily add the ".:" to the
beginning of the explicit classpath themselves
#KT-17100 Fixed
The <Type>Array.iterator used to lack next<Type>() method (KT-16626).
The -Xtypedarray compiler key enables translation of primitive arrays
to TypedArrays, and primitive array`is`-checks (KT-15358, KT-14007,
KT-14614, KT-16056).
The inheritance is still needed because of the code in intellij-core,
specifically in JavaCoreProjectEnvironment.addSourcesToClasspath and
CoreJavaDirectoryService.getPackage, which assumes that the
JavaFileManager instance in the project is a CoreJavaFileManager
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
Denis Zharkov