Why did the problem existed?
At first, lambdas were analyzed with suspend function expected type,
because it's the WHEN-case and we propagate expected type info to
the branches.
Then, after the lambdas was introduced to the containing inference
system, we're creating ResolvedLambdaAtom using the information
from analyzed lambda's shape, but didn't use known lambda resulting
type (from which we might infer FunctionTypeKind).
So, the fix is just using that already obtained information.
^KT-57446 Fixed
On some platforms, `NSUInteger` is 32-bit, while the objc_direct tests
expected it to be represented as `ULong`. So the tests failed on those
platforms.
Fix the tests by replacing `NSUInteger` with `uint64_t`.
The only case when behavior is change is described at
computeNonTrivialTypeArgumentForScopeSubstitutor
The idea is to avoid depending on the presence of @UnsafeVariance
and instead approximate captured types in covariant argument positions
before building substitution scopes
It's correct because for Captured(*) <: Supertype,
Out<Captured(*)> <: Out<Supertype> and when we've got @UnsafeVariance
value parameters at Out, it's ok to allow passing Supertype there.
^KT-57602 Fixed
^KT-54894 Fixed
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
Denis.Zharkov