- encapsulate semantic more into helpers
- allow lazy scopes iteration
- simplify reporting code in tower resolver
- fix some inconsistencies and wrong lookups
- remove redundant lookup recordings
- remove lookup scopes for non-star imports
The commit is a refactoring and doesn't change the behaviour of
neither IC nor CRI. Changes in the lookups are mostly due to the
previous obviously wrong lookups (see changed test data).
This change is needed because otherwise, source files that are not Java will be added as `JavaSourceRoot`, this is incorrect and causes assertion error in `com.intellij.core.JavaCoreProjectEnvironment.addSourcesToClasspath`. Refer to KT-65325 for more context.
Merge-request: KT-MR-14088
Merged-by: Xuan Son Trinh <xuanson.trinh@jetbrains.com>
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
Reimport after `./gradlew build` adds jars from gradle's `build/libs` to facet's classpath. That causes problems with JPS build, because it doesn't see changes in out folder, but see unchanged jar, so changes don't apply.
#KT-51873 Fixed
Merge-request: KT-MR-6018
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
Ilya Chernikov