Makes it easier to introduce a Gradle property for configuring
IncrementalCompilerRunner.
^KT-64513 Fixed
^KT-63837 In Progress
Merge-request: KT-MR-13671
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@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.
In commit 4e89dcf, we have prepared the API for IC maps in top
interfaces and provide the implementation in abstract classes.
In this commit, we refactor IC maps so that they directly inherit/reuse
the implementation from the superclasses without having to reimplement
the APIs for a map.
Test: Existing tests (refactoring change)
^KT-63456: In progress
Authored-by: Hung Nguyen <hungnv@google.com>
Merge-request: KOTLIN-MR-801
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
To support build cache relocatability, we need to convert absolute paths
into relative paths before storing them in IC caches.
Before this commit, we computed relative paths based on the (root)
project directory and FAIL if some source files are located outside the
project directory.
With this commit, we will NOT FAIL in that case. This means relative
paths may start with "../". It's not "clean", but it can work.
Test: New test in BuildCacheRelocationIT
^KT-61852 Fixed
Adding these dependencies to the `api` configuration pollutes classpath for each dependant modules even if it doesn't need them. Instead, the dependencies should be declared more granularly if they're required
#KTI-1349 In Progress
IC caches often contain file paths. To make them relocatable, we need
to convert these file paths into relative paths, relative to a base
directory.
- If the file paths are source files, we can use the root project
directory as base.
- If the file paths are class files, we should use the classes
directory as base (before this commit, we used the root project
directory in both cases, that's why we hit KT-58547).
The key changes in this commit include:
- RelocatableFileToPathConverter: converts paths to relative paths
- IncrementalCompilationContext: contains 2 different path converters,
one for source files and one for class files
- SourceToOutputFilesMap: maps source files to class files using the
above path converters
- IncrementalCompilerRunner: creates the path converters based on file
locations
Test: RelocatableFileToPathConverterTest unit test
SourceToOutputFilesMapTest unit test
BuildCacheRelocationIT.testCustomBuildDirectory integration test
^KT-58547 Fixed
A constant is a static final field with non-null value. In a previous
commit (0b09be7), we accidentally removed the *non-null value*
filter when looking for constants in the bytecode.
This commit re-adds that filter to make sure the detection is correct.
Test: Added KotlinOnlyClasspathChangesComputerTest.testDelegatedProperties
^KT-58986: Fixed
Both the new and old incremental compilation (IC) analysis rely on
Kotlin class metadata to detect a change.
However, Kotlin metadata currently doesn't contain info about
annotations (KT-57919), so the IC will not be able to detect a change
to them.
With this commit, we'll fix the new IC such that it can detect a change
to class annotations by not relying only on metadata.
We currently scope this fix to the new IC (cross-module analysis) first.
We'll fix this issue for within-module analysis later.
Performance: There seems to be no performance impact from this change.
Snapshotting the 400MB ideaIC-2022.1.4/app.jar takes 4.1s before and
after this change.
Test: Added ClasspathChangesComputerTest.testChangedAnnotations
^KT-58289: Fixed
Previously, when snapshotting the classpath with
`ClasspathEntrySnapshotTransform`, for each jar we load all classes
in memory at once. This was needed to detect inaccessible classes
(classes that don't impact incremental compilation and therefore
don't need to be snapshotted).
To reduce memory consumption, this commit updates the algorithm such
that we can now load one class at a time while still being able to
detect inaccessible classes.
In addition, we now read jar files with `java.util.zip.ZipFile` API
instead of `java.util.zip.ZipInputStream` to avoid current JDK bugs with
`ZipInputStream` (e.g., https://bugs.openjdk.org/browse/JDK-8298530).
^KT-57757 Fixed
^KT-57767 Fixed
Add logic that rebuilds all sources after the last incremental round of each Gradle IC test and compares caches. The same was already implemented for JPS, but not for Gradle. After all rounds of incremental compilation are completed, another clean build from scratch is produced. All caches after the rebuild are compared with the caches of the last round of incremental compilation. This check is necessary because incremental compilation artifacts should depend on the state of the project, source files, and configuration, and not the chain of changes and incremental builds that led to this state. After the launch, there were several tests that did not satisfy the above conditions, and were muted (KT-56681, KT-55195, KT-56242, KT-56698)
#KT-54991 In Progress
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
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>
If you need to mute a test for Gradle IC, the only way is to add exclude pattern and regenerate tests aka remove unnecessary tests. But the filter is absolute, so if you have the same test name in different subfolders (e.g. `pureKotlin/classRemoved/` and `classHierarchyAffected/classRemoved`) you cannot disable only one of them. This commit adds logic to specify which name pattern in which subfolder should be excluded
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
Ilya Chernikov