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
1) Update test data according to K2 compiler output
2) Finally switch logic of choosing compiler runner depends on language version instead of deprecated useK2 flag
#KT-60859 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
The `kotlin-test` dependencies are left untouched as changing them affects publications, thus these versions are independent from the used inside our build
#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
In the IDE, there might come declarations from other files/modules
that we link against, but not compile. Type parameters are one of such
declaration kinds.
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
In this example we get 2 variants of `kotlin/toString()`:
one coming from the KLib provider, and the
other coming from the builtins provider.
These are identical deserialized functions.
^KT-57601 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
It acts as a workaround for the case when build tools or dependencies
are compiled with latest 'kotlin-stdlib' version, but at a runtime older
'kotlin-stdlib' is provided, which does not know about new
`EnumEntries`.
^KT-57317 Fixed
Ivan Kochurkin