otherwise they are easily swallowed by the reporting logic.
This commit was needed to ensure that the problem described in
KT-63665 is reproducible in IC test
But some JS IC logic relies on handling compiler exceptions as a signal
for scope expansions, and the newly introduced exception logging
broke a few tests. To mitigate it, the directive was introduced
to disable exception logging for particular test.
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>
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
*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
Test: Existing IncrementalJvmCompilerRunnerTestGenerated.PureKotlin#testCompanionConstantChanged
and similar *.PureKotlin#testCompanionConstantChanged tests
Fix testdata of new compiler tests for JPS, as it is build-log-sensitive:
ClassHierarchyAffected.testWithIntermediateBodiesChanged
PureKotlin.testSerializedSubClassAndChangedInterfaces
WithJava.JavaUsedInKotlin.testRawErrorTypeDuringSerialization
Mute JavaUsedInKotlin.SamConversions tests, as it was fixed in 212 idea
Add missed part of commit 5f4be072 [JPS] Fix JS incremental compilation
Part of commit, located in JPS module, was missed during JPS relocation
Fix test MixedInheritance for non-JPS builds
Depends on commit [CHERRY PICKED FROM IJ] [testdata] Replace test IncrementalJvmJpsTest...
Replace test because JPS recompile inherited classes only in case of existence of direct use (like override or direct call of parent methods).
Tested cases:
*Add new abstract method when derived class does not abstract
*Add and remove method, when such method is present in derived class
*Change return type/access modifier
GitOrigin-RevId: 767e58ba3d3e4069838c717666329b43f1b8e936
Original commit: https://github.com/JetBrains/intellij-community/commit/d738c61aaefe95acd8130066f53f8d8bcadfa977
Fix test IncrementalJvmJpsTestGenerated$PureKotlin.testPackageFileAdded
Fix test IncrementalJvmJpsTestGenerated$Custom.testCommonSourcesCompilerArg
Fix test IncrementalJvmJpsTestGenerated$WithJava$JavaUsedInKotlin$SamConversions.testMethodAddDefault
GitOrigin-RevId: 63b7a47898ca42b4d7f11a01ceb0e019933f528b
Original commit: https://github.com/JetBrains/intellij-community/commit/e91bfb29e65b9eb5452c4d5f544f0bbfa3eafde3
The following tests are outdated (JPS/Js is no longer supported):
- MultiplatformJpsTestWithGeneratedContentGenerated$Simple.testEditingPJsKotlin
- MultiplatformJpsTestWithGeneratedContentGenerated$SimpleNewMpp.testEditingPJsKotlin
GitOrigin-RevId: e4c4b5a75b39803bc5df966a3d957e5ab0f253b1
Original commit: https://github.com/JetBrains/intellij-community/commit/49542e2cce00b08f87c0c91093dff4e8c9df1032
Kirill Rakhman