1) Move root util functions to separate CompileRunnerUtils file from IncrementalJvmCompileRunner to leave the only class instance there and to separate util functions
2) Move TestLookupTracker from the abstract parent class location to a separate file as an implementation class
3) Small change naming of building functions just to clarify what they do
4) Some small code-style refactorings
Using of Kotlin reflection for simple operations like bean management is very slow
First time initialization time: 261 ms for `copyBean(K2JVMCompilerArguments())`
Subsequent calls of `copyBean(K2JVMCompilerArguments())` take 1.7 ms per call
Unfortunately compiler argument handling is also used in Kotlin IntelliJ plugin
to parse facet settings. Big projects may have thousands of Kotlin facets
The same `ArgumentUtilsKt.copyProperties` frame is seen across various freezes:
IDEA-252440 2-3 minutes freeze on Kotlin project reimporting in last 203 eap
IDEA-253107 A lot of short freezes (1-3 sec) during Kotlin project development
KTIJ-23501 Make main run configuration detection lighter
KTIJ-22435 Unresponsive UI with 100% cpu
Reflection issue:
KT-56358 KClasses.getMemberProperties takes too much time
This commit replaces all reflection stuff with a simple code generation
Now `K2JVMCompilerArguments().clone()` goes to hard-to-measure time
Facet serialization is located in Kotlin repo, and it uses new(1.9.*) stdlib in compile dependencies. But when it is used by IJ it has previous runtime stdlib dependency (looks like 1.8.0). So here is workaround, that specifies apiVersion and languageVersion, that does not produce such problematic outputs.
#KTIJ-24903 Fixed
Merge-request: KT-MR-9333
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
IC: Compute symbols impacted by classpath changes
Incremental compilation has 4 key steps:
1. Compile changed/impacted files
2. Detect symbols that have changed after compiling
3. Detect symbols that are impacted by the changed symbols
4. Based on the changed-or-impacted symbols, identify files that need
to be recompiled. Go back to step 1.
Normally, step 2 and 3 are done together when the changed symbols
and impacted symbols are in the same module.
However, if the changed symbols and impacted symbols are in different
modules (e.g., a `Subclass` in lib1 extends a `Superclass` in lib2),
we currently do not compute symbols in the current module that are
impacted by changes in another module (step 3 above).
This is the case for both the new IC and the old IC.
In this commit, we will compute impacted symbols for the new IC. We can
fix the old IC later if necessary (they can't be fixed together easily).
Test: Added BaseIncrementalCompilationMultiProjectIT.testChangeInterfaceInLib
^KT-56197 Fixed
Historically flag was enabled for Gradle projects, but we don't have fir-based JavaTracker for the K2 compiler for now, so we need to use a fallback strategy.
Note: it was disabled for tests with K2
Note2: after adding a fir-based java classes tracker this value should be set to true (KT-57147)
#KT-56886 Fixed
Merge-request: KT-MR-9053
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
Initialization of compiler arguments takes a long time because of its copying, but for initial context check, there is no need to do it at all for all targets except Common.
#KTIJ-21161 In Progress
Currently, FIR compilation of `const val b: Byte = 50 + 50` shows an error, but old compiler doesn't (it shows only warning). Since this is an incremental test, it should not be affected by compiler errors, but should only test for .kt usage without recompilation.
#KT-54991 In Progress
This reverts commit c4a29651 as it is no longer needed after IC fix: `5ba3053e` "[IC] Do not report recompilation of non-existing files", because now fix-ic-build.log duplicates the main build.log
#KT-54991 In Progress
Gradle IC with enabled FIR compilation adds some extra files to the compilation scope compared to the previous compiler(KT-55576). Adding dummy files to such tests with expanded compilation scope will prevent green Aggregate build if some changes in IC will lead to full module compilation as there were such precedents with JS IC because otherwise, all files in the module are present in the build log.
#KT-54991 In Progress
If typealias is defined in a separate file, then after changing some base types, an incremental compilation of Kotlin could not find all affected files, because of lack of information, which it can not get on the class file analyzing phase. FIR provides a new approach to IC compilation: now we can run the frontend several times, which allows us to obtain all necessary information and use it to mark all affected files for recompilation.
Relates to KT-54991
#KT-28233 Fixed
manifested in the IC tests by a seemingly redundant lookup,
although theoretically may lead to more severe issues.
Also fixes lookup recording ignoring logic, since the old
one may break with the new us-site file calculation.
#KT-55195 fixed
*Enable JPS tests for K2
*Exclude compiler messages from the comparison of output logs, as they can vary depending on the compiler
*Mute failing tests:
1) Sam conversions - Unmute after updating IntelliJ core up to 212, as they should pass after updating IntelliJ JPS dependency
2) Failing IC tests with Java-interop, that are needed to be fixed during KT-55696
3) Failing IC tests with recording different sets of lookups by the compiler, that are needed to be fixed during KT-55195
4) Failing AllConstants, will be changed in KT-54991
*Fix test data:
1) Add cleaned outputs for JPS, because Gradle skips error messages at all
2) Rename gradle-fir-build.log to fir-build.log, because JPS also can use it and there is no need to duplicate files
3) Add some k2-specific logs, that changed the set of files in different rounds in comparison with the old compiler, but the scope stays the same
4) Remove useless logs and obsolete directives.txt files as they have no impact on test results
5) Replace fir-build.log files with gradle-fir-build.log because Gradle build with FIR is correct, but not optimal. JPS with K2 is now tested with fir-build.log files
6) Remove useless fir-log, as it duplicates the main build log, and Remove empty directives file
#KT-54991 In Progress
Merge-request: KT-MR-8174
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
Optional-expectation annotations which have an actual counterpart should
have never been serialized to the kotlin_module's proto. See for example
the original (correct) implementation in the old JVM backend in
`PackageCodegenImpl.addDescriptorToOptionalAnnotationsIfNeeded`.
#KT-55611 Fixed
If we detect a change in an inline function `foo` with @JvmName
`fooJvmName`, we have two options:
1. Report that function `foo` has changed
2. Report that method `fooJvmName` has changed
Similarly, if we detect a change in an inline property accessor with
JvmName `getFoo` of property `foo`, we have two options:
1. Report that property `foo` has changed
2. Report that property accessor `getFoo` has changed
The compiler is guaranteed to generate `LookupSymbol`s corresponding to
option 1 when referencing inline functions/property accessors, but it is
not guaranteed to generate `LookupSymbol`s corresponding to option 2.
(Currently the compiler seems to support option 2 for *inline*
functions/property accessors, but that may change.)
Therefore, we will choose option 1 as it is cleaner and safer.
^KT-54144 In progress
Small cleanup in IncrementalCompilerRunner
- Add comment for closing caches
- Rename providedChangedFiles to changedFiles
- Tiny clean up in `performWorkBeforeCompilation`
- Count directories to delete in debug logs
^KT-53015 In progress
Extract KotlinClassInfo to a separate class
to reduce the size of IncrementalJvmCache and prepare for the next
change.
^KT-54144 In progress
Ignore inline functions that are not found in the bytecode
^KT-54144 In progress
Add unit test for handling `@JvmName`s
Test: KotlinOnlyClasspathChangesComputerTest
#testFunctionsAndPropertyAccessorsWithJvmNames
^KT-54144 Fixed
Update unit tests for handling `@JvmName`s
In a previous commit, we made a behavior change for inline property
accessors: The existing behavior is that if the implementation of an
inline getter has changed, only usages of the getter will be impacted
but not usages of the setter (and vice versa).
After that previous commit, usages of *both* the getter and setter will
now be impacted (i.e., we might compile slightly more files). This is
because a change to either the getter or the setter will now be
considered a change to the property, which will help simplify our change
analysis.
This commit updates the relevant unit tests to reflect the new behavior.
Test: Updated Incremental*TestGenerated.PureKotlin#testInlinePropertyInClass
and Incremental*TestGenerated.PureKotlin#testInlinePropertyOnTopLevel
^KT-54144 Fixed
The logic of detecting changes in Kotlin facets was changed from "Include selected fields" to "Include all compiler arguments and exclude selected". This will help to avoid multiple IC issues when new change-sensitive compiler arguments will be added
(#KTIJ-17137, #KT-51536, #KTIJ-17170, #KTIJ-17300, #KT-47983) Fixed
Merge-request: KT-MR-7455
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
[JS] Remove incremental js jps test
[JS] Remove test of maven js archetype
[JS] Fix another one test
[JS] Fix tests for jps
[JS] Try to fix maven test data
[JS] Fix test data
[JS] Fix test data for ant
[JS] Fix jsExtraHelp test
[JS] Fix test run from not-Gradle build tools
[JS] Set flag without compiler error
[JS] Disable warnings and errors in legacy compiler called from Gradle
[JS] Proofread messages
[JS] Not proofread messages
KT-42326
- just legacy - report warning about deprecation
- both - report warning about deprecation of legacy
- no compiler explicitly chosen - error about explicit setting compiler
warn from cli legacy compiler
nowarn flag - kotlin.js.compiler.nowarn
KT-42326
KT-53074
Mikhail Glukhikh