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