^KT-55808 Fixed
Review: https://jetbrains.team/p/kt/reviews/8401
If I don't bump `versions.kotlin-native` then locally
`kotlinx.coroutines` & `kotlinx.atomicfu` user projects compilation
fails with message:
```
w: skipping /home/bobko/jb/kotlinx-atomicfu/atomicfu/build/classes/kotlin/metadata/commonMain. Incompatible abi version. The current default is '1.7.0', found '1.8.0'. The library produced by 1.8.255 compiler
e: Could not find "/home/bobko/jb/kotlinx-atomicfu/atomicfu/build/classes/kotlin/metadata/commonMain" in [/home/bobko/jb/kotlinx-atomicfu, /home/bobko/.konan/klib, /home/bobko/.konan/kotlin-native-prebuilt-linux-x86_64-1.8.20-dev-5812/klib/common, /home/bobko/.konan/kotlin-native-prebuilt-linux-x86_64-1.8.20-dev-5812/klib/platform/linux_x64]
```
It worth noticing that we hardcoded "1.9.0-dev-693" on CI
(kotlin-teamcity-build/6693cb229c7485e07241fbc28322344774bcc3e0) to
workaround KTI-1107. 1.9.0-dev-693 also bumps KotlinAbiVersion
Review: https://jetbrains.team/p/kt/reviews/8401
In scope of: KT-55082
Because this version isn't used for anything. We have KotlinAbiVersion
to version the IR format.
Review: https://jetbrains.team/p/kt/reviews/8401
- Code style
- Drop unused properties in kotlin-native/build.gradle
- kotlin-native/build.gradle: drop unused import
- use final instead of open when possible
This is just a cleanup commit. It neither fixes any issue/bug, nor
introduces new behaviour.
Feel free to revert this commit if you find out that it breaks something
* Replace it with KotlinCompilerVersion
* K/N version should be set now with `deployVersion`.
* Cleanup deprecated functions in older versions
of the Gradle plugin
* Cleanup tests for older versions of compiler downloader
Merge-request: KT-MR-8436
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
This allows the compiler to limit imports from "magic" packages like
cnames.structs to forward declarations actually present in dependent
cinterop klibs.
The manifest already had `exportForwardDeclarations` field, but
- it didn't include Objective-C forward declarations (@class, @protocol)
- it has a slightly different meaning (the export list enables importing
the listed declarations through the interop package of the library,
while the include list shouldn't do that), so we better avoid mixing
them.
Review: https://jetbrains.team/p/kt/reviews/8360
MetadataComparisonTest was the only one in build-tools module who
depended on util-klib, that's why we can drop build-tools -> util-klib
dependency
MetadataComparisonTest is no longer needed, that's why we can drop it.
The dependency drop is a one step forward in dropping
`kotlin.srcDir("../compiler/util-klib/src")` line in
`buildSrc/build.gradle.kts`. Adding source roots in `buildSrc` is hacky
and can lead to frustrations (e.g. KT-55874). That's why it's desirable
to drop buildSrc -> util-klib hacky dependency.
Unfortunatelly, I couldn't drop buildSrc -> util-klib dependency,
because:
1. buildSrc depends on kotlin-native/shared/src/library/kotlin +
buildSrc depends on kotlin-native/tools/kotlin-native-gradle-plugin +
maybe smth else
2. kotlin-native/shared/src/library/kotlin depends on util-klib +
kotlin-native/tools/kotlin-native-gradle-plugin depends on util-klib +
maybe smth else
When loading default libraries, the code assumed that all subdirectories
of <kotlin native home>/klib/*/ corresponded to valid libraries. The bug
report only considers the case of .DS_STORE, which is generated by
Finder on MacOS, but this case has already been accounted for in the
code.
The fix filters out all subdirectories that are not stdlib and don’t have the
“org.jetbrains.kotlin” prefix.
Co-authored-by: Troels Lund <troels@google.com>
KLIB forward compatibility was broken during work related to
definitely not-null types, but version was not changed. This led to
exceptions in compiler instead of meaningful error.
^KT-52518
Calling FileSystems.newFileSystem(URI, ...) throws a
FileSystemAlreadyExistsException if a ZipFileSystem for this
URI is already created. We still can use a single instance
of ZipFileSystem by calling FileSystems.getFileSystem. In
this case we use reference counting to determine when this
instance can be safely closed.
But we cannot count references if the same ZipFileSystem is used
from different class loaders. This patch fixes this issue by
creating a file system from Path instead of an URI. Contract of
FileSystemProvider.newFileSystem(Path, ...) doesn't imply throwing
FileSystemAlreadyExistsException.
Issue #KT-37443 fixed
Nikita Bobko