CacheVersion class refactoring:
Responsibilities of class CacheVersion are splitted into:
- interface CacheAttributesManager<Attrs>, that should:
- load actual cache attribute values from FS
- provide expected attribute values (that is required for current build)
- checks when the existed cache (with actual attributes) values is suitable for current build (expected atribute values)
- write new values to FS for next build
- CacheAttributesDiff is created by calling CacheAttributesManager.loadDiff extension method. This is just pair of actual and expected cache attributes values, with reference to manager. Result of loadDiff can be saved.
CacheAttributesDiff are designed to be used as facade of attributes operations: CacheAttributesDiff.status are calculated based on actual and expected attribute values. Based on that status system may perform required actions (i.e. rebuild something, clearing caches, etc...).
Methods of CacheAttributesManager other then loadDiff should be used only through CacheAttributesDiff.
Build system should work in this order:
- get implementation of CacheAttributesManager for particular compiler and cache
- call loadDiff __once__ and save it result
- perform actions based on `diff.status`
- save new cache attribute values by calling `diff.saveExpectedIfNeeded()`
There are 2 implementation of CacheAttributesManager:
- CacheVersionManager that simple checks cache version number.
- CompositeLookupsCacheAttributesManager - manager for global lookups cache that may contain lookups for several compilers (jvm, js).
Gradle:
Usages of CacheVersion in gradle are kept as is. For compatibility this methods are added: CacheAttributesManager.saveIfNeeded, CacheAttributesManager.clean. This methods should not be used in new code.
JPS:
All JPS logic that was responsible for cache version checking completely rewritten.
To write proper implementation for version checking, this things also changed:
- KotlinCompileContext introduced. This context lives between first calling build of kotlin target until build finish. As of now all kotlin targets are loaded on KotlinCompileContext initialization. This is required to collect kotlin target types used in this build (jvm/js). Also all build-wide logic are moved from KotlinBuilder to KotlinCompileContext. Chunk dependency calculation also moved to build start which improves performance for big projects #KT-26113
- Kotlin bindings to JPS build targets also stored in KotlinCompileContext, and binding is fixed. Previously it is stored in local Context and reacreated for each chunk, now they stored in KotlinCompileContext which is binded by GlobalContextKey with this exception: source roots are calculated for each round, since temporary source roots with groovy stubs are created at build time and visible only in local compile context.
- KotlinChunk introduced. All chunk-wide logic are moved from KotlinModuleBuildTarget (i.e compiler, language, cache version checking and dependent cache loading)
- Fix legacy MPP common dependent modules
Cache version checking logic now works as following:
- At first chunk building all targets are loaded and used platforms are collected. Lookups cache manger is created based on this set. Actual cache attributes are loaded from FS. Based on CacheAttributesDiff.status this actions are performed: if cache is invalid all kotlin will be rebuilt. If cache is not required anymore it will be cleaned.
- Before build of each chunk local chunk cache attributes will be checked. If cache is invalid, chunk will be rebuilt. If cache is not required anymore it will be cleaned.
#KT-26113 Fixed
#KT-26072 Fixed
- support common modules metadata compilation under flag (it is not required since all common source roots are included transitively for now)
- introduce expect actual tracker in jps: move implementation from gradle to build-common
- support js incremental compilation: move implementation from gradle to build-common
Android Gradle plugin will start publishing clases in directories.
This commit adds support to find build history files when changed
files come from directories. It is similar to existing implementation
for jars i.e. it looks for .kotlin_module file under META-INF.
Test: ModulesApiHistoryAndroidTest
Each Kotlin task now writes build history to separate file.
A map of output directories to history files is used to get changes for
modified files.
#KT-22623 fixed
Creating and disposing CoreApplicationEnvironment on each call leads to
problems with parallel builds, while KotlinCoreEnvironment
avoids disposing application environment in case of parallel builds.
#KT-23694 fixed
When TestLoggerFactory is initialized in tests it checks that variable
and it it's not present uses classpath to search for logger configuration.
If this search is unsuccessful a lot of exceptions are written to log:
java.lang.RuntimeException: Could not find installation home path. Please make sure bin/idea.properties is present in the installation directory.
at com.intellij.openapi.application.PathManager.getHomePath(PathManager.java:96)
at com.intellij.testFramework.TestLoggerFactory.reconfigure(TestLoggerFactory.java:67)
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Otherwise IC fails when a project declares a class with the same name
as in one of its dependencies.
The issue is relevant only for non-JPS IC (Gradle, Maven, etc.),
but I added the test for JPS too.
#KT-20516 fixed
A directory-after-rebuild should correspond to expectedDir parameter,
a directory-after-IC should correspond to actualDir parameter.
Also we should not forgive extra directories.
In some cases IC needs to perform a rebuild.
Before this change IC was not clearing output directories
besides destination dir for classes, so for example
kapt stubs were not cleared.
Stalled stubs might lead to compile errors.
For example:
1. foo/XGen.java is generated from annotated class foo/X (XGen also
references X).
2. foo/X is moved to bar/X and some other change forces IC to rebuild.
3. kapt generates bar/X stub, but foo/X stub
was not removed because stubs dir is not cleared.
4. kapt runs annotation processors, foo/XGen.java is generated from
foo/X stub, bar/XGen.java is generated from bar/X stub.
5. kotlinc rebuilds. Since destination dir is cleared properly,
only bar/X.class exists.
6. javac tries to compile foo/XGen and fails, because it
compiles against actual Kotlin classes, not stubs.
This commit fixes the issue by passing all output directories
of a task from Gradle to Kotlin IC.
#KT-21735 fixed
Ilya Gorbunov