Overriding equals, hashCode, toString and any other member that is not
expect does not require satisfying the rules of expect-actual matching.
#KT-57381 Fixed
If the compiler runtime JDK is 9+,
it will already contain JrtFileSystemProvider and won't use provided
classloader
In order to fix KT-57154 we need to provide "java.home" argument to
newFileSystem
In order to reduce the severity of the leak in KT-56789 we cache
instances of FileSystem itself forever
Otherwise, each invocation of newFileSystem on JDK 9+ will leak
classloader, which is created deep inside the JDK code
Add unit test for JRT-FS contents served through CoreJrtFs
Add Gradle Integration test to
test if the daemon correctly reads JDK contents from the specified
toolchain and not from its runtime JDK
^KT-57154
Regression test for ^KT-57077
Kotlin/Native codegen needs to deserialize all fields throughout the class hierarchy to build the proper binary class layout. That becomes impossible with the guard condition that prevents loading private top-level classes from another module in LazyIR (see https://github.com/JetBrains/kotlin/blob/2a4d8800374578c1aa9ec9c996b393a98f5a6e3b/kotlin-native/backend.native/compiler/ir/backend.native/src/org/jetbrains/kotlin/backend/konan/serialization/KonanIrlinker.kt#L701). The guard suits well for the partial linkage needs, but it causes the codegen to fail with `Unbound public symbol IrClassPublicSymbolImpl: [ File '/file/in/the/library.kt' <- private.top.level/ClassDeclaration|null[0] ]` error.
To prevent this the guard is removed. This does not influence the partial linkage in general except for the different error message being generated: `Function 'foo' can not be called: Private function declared in module <A> can not be accessed in module <B>` instead of `Function 'foo' can not be called: No function found for symbol '<symbol>'`.
#KT-54469
- An `OptionalAnnotationClassesProvider` only needs to be created if the
package part provider may even have optional annotation classes.
- In the IDE case, the package part provider never provides optional
annotation classes, so especially in the IDE, we can avoid a lot of
useless symbol providers with this.
This fixes an issue where an actual class from an intermediate module
has more supertypes than its expect declaration which leads to a
false-positive resolution error because a type reference resolves to the
expect class. The fix is to sort the dependencies topologically from
"most actual" to "most expect" when creating the list of symbol
providers.
#KT-57369 Fixed
It's a common compiler argument and may be applied to any compile task, there's no reason to set it separately for K/JS and K/JVM, and now it sets the compiler argument for metadata compilation tasks as well
Kirill Rakhman