* Support flags with any value (not just Boolean)
* Support all flags by parsing arguments in KotlinFacetSettings, instead
of manually listing known flags
#KT-19210 Fixed
Original commit: 2f99f6ad34
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
Original commit: e32880d9a3
- separate compileLibraryToJar into two public functions, for JVM and JS
- allow to pass any extra options instead of just -Xallow-kotlin-package
- add a bunch of default arguments for the most common cases
Original commit: 8af923c5ff
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
Original commit: a802e7fb71
Remove intellij-core from dependencies of modules which already depend
on frontend or any module that exports frontend (such as frontend.java)
Original commit: 7febd846e8
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
Original commit: b06b18de07
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
Original commit: 965b4199f4
1. Determine source element for descriptors with NO_SOURCE recursively.
2. Always provide type abbreviation for type alias constructor
return type.
#KT-15495 Fixed
Original commit: a2db4dc0d5
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.
Original commit: 8903504334
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.
Original commit: 2e9a59819a
- 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)
Original commit: fcf44af294
- Don't print "Loaded plugin: KotlinAndroidJpsPlugin" and "Using
kotlin-home = ..." for every build. They are rarely useful; they can
be found in the build log now
- Instead of potentially confusing for the user "Kotlin JPS plugin
version ..." output simply "Kotlin version ...". Also add the version
of the JRE, where the compiler is being run
- Do not treat messages reported with severity LOGGING as BuildMessage
with kind PROGRESS. Such build messages are displayed to the user in
the progress/status bar when IDEA Make process is running, but LOGGING
messages never had this meaning. In particular, users could be
confused by the progress bar message "Kotlin: Configuring the
compilation environment" visible for a very long time during
compilation. This message just happens to be the last LOGGING message
reported by the compiler before the actual compilation; its presence
there created an illusion that Kotlin spends most of the time
configuring the compilation environment
#KT-17387 Fixed
Original commit: bb01ca038a
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
Original commit: d8d3bafbe9
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.
Original commit: 05c3e7e81d
This is mostly a revert of f936dea8, where the issue of the compiler
failing on repeated command line arguments was worked around. Now the
compiler behaves more properly: it uses the last passed argument and its
value, and prints a warning that several values have been passed. With
this behavior, the workaround is no longer necessary
Original commit: dc5e51f4ac
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)
Original commit: be54e4b93b
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 ff783f1f and 2c344635)
#KT-16931 Fixed
Original commit: c67eb84369
Relates to KT-15562 "Service is dying".
This commit includes multiple changes:
1. JPS & Gradle daemon clients are refactored to use `connectAndLease` from `KotlinCompilerClient`.
`connectAndLease` was introduced in previous commits
2. `withKotlin` was removed because `connectAndLease` already covers retrying on connection error
3. Gradle flag files creation is changed:
* client-alive flag file lives as long as Gradle instance lives,
* session-alive flag file lives until the end of a build.
Original commit: 9d95c841a6
Before this change a daemon client debug messages were printed
only when the client could not connect and the 'kotlin.daemon.verbose'
system property was set up.
Now messages are printed if the debug logging is enabled and
the 'kotlin.daemon.verbose' is set up.
Original commit: 9819de1abd
Alexey Tsvetkov