Consumer configurations with following set of attributes:
* org.gradle.usage = 'kotlin-api'
* org.jetbrains.kotlin.platform.type = 'common'
are supposed to consume legacy `*.kotlin_metadata` artifacts.
And can be consumed by HMPP project with
"Compatibility Metadata Variant Enabled" flag. For such purpose
`metadataCompileClasspath` configuration is configured with attributes
mentioned above.
There is no sense to consume such artifacts in HMPP projects without
compatibility metadata variant. And in order to prevent
breaking changes in KGP ecosystem, legacy configurations are
reconfigured to consume new KLIB metadata artifacts. Instead of failing
on resolution.
^KT-50925 Verification Pending
This enables using exported Frameworks with `-fmodules-decluse`.
One use-case for this is ensuring that distributed builds are
explicitly providing all required modules; this is important for
reproducibility.
For more background on `use` declarations, see:
https://clang.llvm.org/docs/Modules.html#use-declaration
The easiest way to reproduce this locally is by compiling a framework,
and emitting a pcm file with `swiftc`. Note that this requires a
reference to a pcm for Foundation, which can be found in the clang
ModuleCache.
```
kotlin-native/dist/bin/kotlinc-native ~/test.kt -produce framework -o /tmp/TestFramework.framework
swiftc -emit-pcm -module-name TestFramework -o /tmp/TestFramework.pcm /tmp/TestFramework.framework/Modules/module.modulemap -Xcc -fmodules-decluse -Xcc -fmodule-file=Foundation=$HOME/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/1IQ2SWDEIAPH0/Foundation-2FJBXN8U6QRTS.pcm
```
^KT-51627 Fixed
kotlinc will currently read /tmp/build.txt in an attempt to
determine an IDEA version number for IDEA plugin compatibility
checking. If that file exists and does not match the expected
format kotlinc will fail.
Since standalone kotlinc is not IDEA, this change explicitly
sets the system property for the build number to a fallback
value. That avoids reading /tmp/build.txt.
closes https://github.com/JetBrains/kotlin/pull/4763
because the intention of that configuration is to use "slower" class
reading.
In the near future, even though FIR is enabled, which uses experimental
faster jar file system, FIR clients (e.g., FIR UAST or Android Lint) may
still need to use slower class reading. So, we need to handle that
configuration before checking others.
[Gradle, JS] Use empty adapter to just dry run
[Gradle, JS] Not dry run, but full run
[Gradle, JS] Fix test to be failed without dry run
[Gradle, JS] Not use client twice
[Gradle, JS] Add test on mocha failing
[Gradle, JS] Fail mocha in case of infrastructure problems
Merge-request: KT-MR-5802
Merged-by: Ilya Goncharov <Ilya.Goncharov@jetbrains.com>
^KT-51623 fixed
- Huge refactoring for IC
- Update hash combination logic
- Introduce value class for IC hashes
- Calc md5 directly by function IR
- Split IC logic by classes
- Move JsIrLinkerLoader into separate file
- CacheUpdateStatus is a sealed class
- Render TYPE_PARAMETER reified flag
^KT-51081 Fixed
^KT-51084 Fixed
[JS IR] Add tests with external funs and global vals
[JS IR] Non module cases are exceptions for naming
[JS IR] Use fqn for jsModule on declaration
[JS IR] Add test on same external names
Merge-request: KT-MR-5901
Merged-by: Ilya Goncharov <Ilya.Goncharov@jetbrains.com>
^KT-51438 fixed
fixes the case then the function being inlined is taken
from the binaries compiled on the previous iteration, and therefore
should be treated similarly to a fun from a library.
It's not possible to check the exact method signature, as it is
unavailable in dumb stubs for Kotlin's light classes. Yet, it's still
possible to check more things, such as parameter count and access flags.
'ClsClassImpl' instances created by the platform contain synthetic
enum methods (added by 'ClassInnerStuffCache.calcMethods()'). Such
convention is common in IntelliJ (see KT-36095 and
'9a8b345adaded83fe13980a28db5d9f9acc7450d' in the IntelliJ repository).
This commit makes Kotlin's stub-based classes consistent with the
convention. Instead, a filter is added in place of 'ClsClassImpl' usage.
See also the following commits:
- 7c86911f44
- 43468c6d55
'KotlinClassInnerStuffCache' was copy-pasted from the platform's
'ClassInnerStuffCache' several years ago. After J2K and other changes,
it became quite dirty.
Besides cleaning things up, enum synthetic method handling have
significantly improved. Before, such methods were handled only in
'processDeclarationsInEnum', and 'getMethods()' didn't return them.
This led to inconsistent behavior and was reason for providing special
ad-hoc support in '1b6ded600518176b21cc308ed3e032ef8d04cc90'.
Anton Lakotka