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
The only test that fails without is FirOldFrontendLightClassesTestGenerated.
While there's no proof that code fails in production, the footprint from
services shouldn't be big, and it's better to have them instead of
failing in runtime.
KTI-1114
The `ConcurrentCollectionFactory` class was moved to the module
which is no longer available in the 213 platform distribution
`MapMaker().weakKeys().makeMap()` is used as drop-in replacement of
concurrent hash map with identity-based equals strategy
The new implementation stores keys on weak references, which should not
change the behavior of the `ModuleFileCacheImpl`.
1. If someone still has a strong reference to the `ktFile`, then the
cache will also keep it.
2. If there are no more strong references to the `ktFile`, then the
cache will not hold it from being garbage-collected. However, since
nobody has a strong reference to the `ktFile` anymore, nobody can call
`fileCached` or `getCachedFirFile` with it, and it will never be
requested from the cache.
KTI-1114
As there is no accurate way to figure out exact dependencies for each
library JAR, all project libraries but the current one are added as
dependencies. However, for performance reasons, each library is not
treated as an individual 'LLFirLibrarySession', instead a scope-based
'JvmClassFileBasedSymbolProvider' is used.
Although code analysis is correct with this setup, navigation between
libraries was broken. The reason is that source declarations were only
queried inside the library itself.
After the fix, declarations are first queried in the library,
and if there are no good candidates, all other libraries are scanned.
The same way things work in the Java plugin.
^KTIJ-23073 Fixed
Fixes #KT-57647
For value classes, if you add code to companion anonymous init block in IR, it will be executed in the instance constructor. This causes an error when initializing static fields, because writing to them can only occur from the <clinit> method.
The solution is to transfer the static field initialization code from an anonymous init block to the IR initializer of this field
Merge-request: KT-MR-9633
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
After fixing of KT-13995 (99de93bb) there is a case when several maven plugins register the same source roots twice, which leads to the Kotlin compiler exception "Too many source module declarations found". kotlin-maven-plugin should take care of what it passes to the Kotlin compiler to avoid it
#KT-58048 Fixed
Merge-request: KT-MR-9716
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
Warning Context:
> Task :js:js.tests:generate-ts-for-regular-classes-in-exported-file
Execution optimizations have been disabled for task ':js:js.tests:generate-ts-for-regular-classes-in-exported-file' to ensure correctness due to the following reasons:
- Gradle detected a problem with the following location: './js/js.translator/testData/typescript-export/regular-classes-in-exported-file'. Reason: Task ':js:js.tests:generate-ts-for-regular-classes-in-exported-file' uses this output of task ':js:js.tests:generate-js-export-on-file-for-regular-classes' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.
> generateTypeScriptTests
> tsc --build ./typescript-export/regular-classes-in-exported-file/tsconfig.json
After fixing of KT-13995 (99de93bb) there is a case when several maven plugins register the same source roots twice, which leads to the Kotlin compiler exception "Too many source module declarations found". kotlin-maven-plugin should take care of what it passes to the Kotlin compiler to avoid it
#KT-58048 Fixed
Merge-request: KT-MR-9663
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
This fixes a FIR-specific issue where a type variable is inferred to
Any instead of dynamic. K1 wasn't affected because of a FIR-specific
condition in ResultTypeResolver.
#KT-57962 Fixed
Yahor Berdnikau