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
The command line argument parser is using between 0.25s and 0.5s
(depending on platform) on finding annotated properties. This fix
replaces the slow kotlin reflection with java reflection, which is an
order of magnitude faster.
#KT-58183 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
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
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
Passing 'false' will pass Array or List based arguments multiple times
instead of using the Delimiter.
eg:
compactArgumentValues = true:
"-cp", "library1;library2;library3"
compactArgumentValues = false:
"-cp", "library1", "-cp", -"library2", "-cp", "library3"
Using compactArgumentValues = false can be beneficial
when the many compiler arguments are held in memory.
In this case the raw arguments can intern individual string values, which
is highly effective when the arguments refer to files on disk.
KTIJ-24976
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
This is required to be able to compile KGP and it's dependencies which
set LV to 1.4 when repo will use LV 1.9. This caused by the change how
enums are compiled (KT-48872).
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
With this flag we can distinguish enum classes that have `entries`
property in the compiled bytecode (see `LanguageFeature.EnumEntries`).
This is needed to be able to understand in the frontend whether
`entries` can be called for that class. For Native and JS, this is
currently not possible even if the feature is enabled, but the class
was compiled with disabled feature.
^KT-53929 Fixed
Alexander.Likhachev