In Gradle < 4.7, there's no `ComponentWithCoordinates` interface, and we
need to make sure that none of our classes implementing this interface
are loaded with older Gradle versions.
Instead of that interface, we can rely on Gradle's metadata generation
heuristic that takes Maven coordinates for the variants from the
corresponding publications.
In new MPP, add source sets taking part in more than one compilation to
the tasks' `commonSourceSet` in order to pass them as -Xcommon-sources
Issue #KT-26515 Fixed
* Some of the usages of `kotlinSourceSets` should instead get all the
source set from the source set hierarchies, i.e. including the ones
transitively-participating in the compilation
After all MPP related changes, the `KotlinSourceSet` interface turns out
compatible with the old `KotlinSourceSet`, and, since there are external
usages of `KotlinSourceSet`, it is reasonable to expose the new
interface under the old FQ-name to fix those external usages.
Issue #KT-26498 Fixed
via reflection, e.g. IDEA platform UrlClassloader. This fix allow
kotlin JSR223 host for IDEA to extract classpath from the environment
properly (with appropriate fix on IDEA side as well).
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
* First, it overrides `addCommonSourceSetToPlatformSourceSet` with an
old signature that was drop during migration to 'KotlinSourceSet's
* Second, it uses an extension SourceSet.kotlin that got dropped during
the aforementioned migration
Now, for the old MPP K/N plugin, `addCommonSourceSetToPlatformSourceSet`
is called twice, one time with the new signature and another with the
old one, which it overrides.
Make it the same type as in case of an empty collection, so that
`emptyRange.random()` throws the same exception as `emptyRange.toList().random()`.
#KT-15539
Given there's a Random API in the stdlib, that generates all random primitives, this commit adds the possibility to generate random unsigned integers.
It uses the same implementation from Random.nextInt, nextLong and nextBytes, but uses the appropriate conversions from a signed type to an unsigned type.
The use of the same API guarantees that the distribution is uniform, but this commit adds some unit test to enforce that necessity.
Fixes #KT-25570
- Mark @ContractsDsl as @Experimental
- Move Contracts DSL out from 'internal' package
- Change visibility of ContractsDsl from 'internal' to 'public'
^KT-25274 Fixed
^KT-25495 Fixed
Throw an exception immediately before an overflow becomes observable.
Place check to prevent negative index from indexOf, indexOfFirst.
Do not insert overflow checks for arrays, lists, maps and char sequences.
#KT-16097
Make copyOfRange implementation non-inline in order not to expose
copyOfRangeToIndexCheck implementation detail.
It will be possible to make the function non-inline itself later without
that JvmName trick, when apiVersion 1.2 support is discontinued.
#KT-19489
Sergey Igushkin