Simplify API of InlineConstTracker
In ConstLowering: Move transformer logic to another class to avoid mutable state. Avoid marking all files in module as module. Support of inner classes.
#KT-46506 Fixed
This commit wires necessary components only. The actual classpath
changes will be provided later.
Bug: KT-45777
Test: Existing IncrementalCompilationClasspathSnapshotJvmMultiProjectIT
and IncrementalJavaChangeClasspathSnapshotIT
Now compiler flags with boolean values which are controlled by system
properties could be set in similar way. The following syntax is
appropriate. For setting flag:
'-DflagName,'-DflagName=[y|Y|true|TRUE|yes|YES|on|ON]'
for unsetting flag:
'-DflagName=[n|N|false|FALSE|no|NO|off|OFF]'
This change will allow to start Kotlin daemon instances using different
from the current user JDK version and use it to compile Kotlin files.
Old behaviour, when java executable path is not set, is still working
and still,by default, using current user JDK version.
For example, user for some reason wants to use JDK 1.8 as active one,
but compile current project using JDK 16.
Main goal is to support Gradle toolchains.
^KT-45611 In Progress
Use {de,}capitalizeAsciiOnly and to{Lower,Upper}CaseAsciiOnly where
possible, and stdlib's functions with Locale.US everywhere else.
Otherwise, if the default system locale is Turkish, the capital latin
letter "I" is transformed in toLowerCase to "ı" (see
https://github.com/JetBrains/kotlin/blob/66bc142f92085047a1ca64f9a291f0496e33dd98/libraries/stdlib/jvm/test/text/StringJVMTest.kt#L119),
which for example breaks the codegen for `intArrayOf` in
KT-25400/KT-43405.
Similarly, lower case latin letter "i" is transformed to "İ".
#KT-13631 Fixed
#KT-25400 Fixed
#KT-43405 Fixed
This allows to replace dependency on 'js.frontend' with 'js.config', in
'kotlin-build-common' and 'daemon-common'. Also simplify some other
dependencies.
Pass computed list of changed classpath names to KAPT instead
of relying on the history files to be computed by stub generation.
Also, stop generating classpath history changes during the stub generation.
This commit does not compute the actual changed classpath entries,
and that will be done in the following commits.
#KT-23880
Add support for incremental annotation processors in KAPT. These
processors conform to https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing
specification.
Support is provided by using javac compiler APIs and
recording the source file structure. At runtime, processors
are instrumented with custom Filer that is used to keep track of generated
files. In order to support classpath changes, stub generation task is
used to generated a list of changed FQCNs, and this is simply used by KAPT.
Both worker and non-worker mode are supported.
#KT-23880
#KT-12700 Fixed
To turn build reports, add 'kotlin.build.report.enable=true' to
gradle.properties file
(or pass it in CLI via`-Pkotlin.build.report.enable=true`).
By default build reports are created in
`rootProject/build/reports/kotlin-build`.
Build report dir can be customized via `kotlin.build.report.dir`
property.
1. Checking for COMPILE_DAEMON_CUSTOM_RUN_FILES_PATH_FOR_TESTS was moved to COMPILE_DAEMON_DEFAULT_RUN_DIR_PATH.
Looks like COMPILE_DAEMON_CUSTOM_RUN_FILES_PATH_FOR_TESTS was introduced incorrectly in 220fab0d3f.
Checking of this property was added in DaemonOptions.runFilesPathOrDefault, while DaemonOptions.runFilesPath was internally used in runFilesPathOrDefault and in many other places.
For example DaemonOptions.runFilesPath used to pass this option to daemon server.
So daemon was started with runFilesPath that ignores COMPILE_DAEMON_CUSTOM_RUN_FILES_PATH_FOR_TESTS.
2. JpsKotlinCompilerRunner._jpsCompileServiceSession was leaked between tests.
Fixed by extracting @TestOnly releaseCompileServiceSession() and calling it in tests tearDown()
3. The result of compileWithDaemon was ignored in compileWithDaemonOrFallback.
So, the fallback was never called, and the FAIL_ON_FALLBACK_PROPERTY was actually was never worked.
This was fixed. Also the message was improved to make it easier to find the original fail cause.
The class is used on both server and client, but it was defined in
server module.
Gradle plugin worked, because all classes are present in kotlin compiler
embeddable, but the code was red in IDE (which is correct because
Gradle plugin does not depend on daemon server module).
Vyacheslav Gerasimov