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.
- Display the Kotlin version in kotlin-gradle-plugin. This is needed
because if "-version" is specified in compiler arguments, the "info"
level of the message printed by the compiler in CLICompiler prevents
it from being displayed by default (unless "--debug" is passed to
Gradle).
- Display the version of JRE the compiler is running on. This will be
helpful to diagnose Java 9 related issues in the future.
- In CLI, also display the executable name (kotlinc-jvm or kotlinc-js)
This makes "-verbose" not required for JPS to run correctly and
therefore allows to print more useful debugging stuff in the compiler
and read them in CLI, for example. The output will also be more readable
because there'll be no "output" messages
This prevents .idea/kotlinc.xml from being added with an empty
ArgumentParseErrors object and also fixes
ConfigureKotlinInTempDirTest.testKotlincExistsNoSettingsRuntime11
BaseCompilerSettings.validateInheritedFieldsUnchanged() compares
old and new properties of the compiler settings, and the check requires
ArgumentParseErrors.equals() to be correctly implemented
By default we use the fast implementation in CLI compiler,
but in the most of the tests the old one is enabled
Also add tests on CompiledJava with the fast class reading
implementation
It's only used for CLI compiler, and it should improve performance
of loading Java descriptors from class-files
For IntelliJ, it leads to 10-15% percent speedup of Kotlin Builder
Before this change, we were using a Java model based on Java PSI that
also read class files, but do it less effectively since it performs
some extra work, that we don't need, e.g. eagerly reading all
the inner classes
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
Anton Bannykh