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
Rationaly is that facet importer knows better about which language
versions should be used, so we shouldn't interfere.
Otherwise, Gradle or Maven projects which have upgraded corresponding
plugin to 1.3 will be imported with 1.2 levels, which is undesirable
Version for IDEA 182 does not work properly here (returns null),
so we have to use `DataManager.getDataContext(focusedComponent)` directly
#KT-26399 Fixed
The extraction itself is needed due to different behaviour of related
IDEA functions in different platforms.
Check on null is needed because `createFromAnAction` last argument
cannot be null, otherwise we will get an exception.
Partial fix of KT-26399
There are few more such places. Better fix would be to avoid
situation, when we need to fallback. So in every project these
settings are defined. It means "Latest stable" setting is not good.
#KT-26364 Fixed
Set LATEST_STABLE language version and current version of stdlib to 1.3, set IS_PRE_RELEASE
Remove "EXPERIMENTAL" from 1.3 version description in tests and gradle options
In 4f3f4dd, launch(EDT(project)) was replaced with TransactionGuard.submitTransaction to fix write in write-unsafe context.
Unfortunately submitTransaction will call action immediately if we are already on EDT. This causes IDE freeze.
By replacing submitTransaction with submitTransactionLater we are postponing work to the end of events queue (as it was before 4f3f4dd).
Also in isUnitTestMode we need to call action immediately as it was before 4f3f4dd.
#KT-25958 Fixed
Android Studio has at least two kinds of importers: a generic one (that is run when the "Refresh Gradle model" tool button is pressed) and a fast one (is run on the build variant switch). Fast importer doesn't invoke our import handlers (AndroidExtensionsGradleImportHandler) that modify the compiler options stored in Kotlin facet in some way.
Until the recent MPP importer refactoring both old and new options were saved in the Kotlin facet; now only the new options persist. This is certainly better, though it breaks the existing behavior (as the options added by import handlers become lost).
The alternative approach is to re-design import handlers in a way they won't require the whole module/source set node (so we can invoke them every time), though it requires a way more changes.
In some tests with txt (probably all except loadJava), property
accessors are not rendered at all, so a third option value (NONE) will
be useful to determine whether we need to render annotations on property
accessors as get/set/sparam-targeted annotations on the property
Yan Zhulanow