Follow-up of 9b3e17f0. There we decided to complete call if a type
variable from a return type has proper lower constraints, now we refine
this rule wrt `Nothing`-like constraints to avoid inferring type variables
to Nothing, which is quite useless
#KT-30370 Fixed
Provide UArraysKt class in kotlin.collections for binary compatibility
instead of removed multipart facade class. It contains only non-inline
functions of the latter.
Caused by: java.lang.ClassCastException:
kotlin.collections.EmptySet cannot be cast to java.lang.Void
at org.jetbrains.kotlin.codegen.coroutines.CoroutineTransformerMethodVisitorKt.findSafelyReachableReturns(CoroutineTransformerMethodVisitor.kt:984)
Co-authored-by: Alexander Udalov <alexander.udalov@jetbrains.com>
In Kotlin/Native 1.3.30 EAP1 an ability to build
a static ObjC framework has been added. This patch
adds support for this feature in the kotlin-multiplatform
plugin.
This patch adds a separate Gradle plugin allowing
a user to import Kotlin/Native modules in Cocoapods
projects and use Cocoapods dependencies in Kotlin
code via cinterop.
The plugin when applied does the following things:
1. Add a framework binary for each supported (iOS
or macOS) platform in the project.
2. Add a Cocoapods extension allowing one to configure
Cocoapods dependencies of the project.
3. Create cinterop tasks for each dependency from the
previous point. The tasks are added for main
compilations of each supported platform.
4. Add a task to generate a podspec-file which includes
the framework from the point 1, script to
build it and dependencies from the point 2.
So the Cocoapods import procedure is the following:
1. A user runs `./gradlew generatePodspec`. The plugin
creates a podspec-file with all dependencies.
2. The user adds a dependency on this podspec in his Podfile
and runs `pod install`. Cocoapods downloads dependencies
and configures user's XCode project.
3. The user runs XCode build. XCode builds dependencies and then
runs Gradle build. Gradle performs interop processing and
builds the Kotlin framework. Compiler options and header
search paths are passed in the Gradle from XCode environment
variables. After that the final application is built by XCode.
Issue #KT-30269 Fixed
Earlier we used to have two methods: cinterops(Container.() -> Unit) and
cinterops(Action<Container>). It's OK for Groovy DSL but causes resolution
ambiguity in Kotlin DSL. This patch removes the first overload to avoid
this situation. The second overload still can be called in Kotlin DSL
as `cinterops { ... }`.
In 1.3.20 a new binaries DSL was introduced. This
patch deprecates old DSL methods used for binary
configuration in 1.3.0 and 1.3.1x.
Issue #KT-29998 Fixed
Earlier we added interop libraries built for a main compilation
in dependencies of a corresponding test compilation. But we didn't
add them in dependencies of interop libraries built for the test
compilation. It caused cinterop failures when the test compilation
has interop libraries. This patch fixes it by adding main interop
libraries in dependencies of test ones.
Also earlier interop libraries of test compilations were
unintentionally added in apiElements and publication. This patch
fixes this issue too.
Issue #KT-30290 Fixed
Toshiaki Kameyama