As future some Kotlin/Native compilations in the future may have
different platforms within one target, it's more preferable to
access the konanTarget from the compilation, not its target.
The Kotlin/Native stdlib was added to the shared-native source sets
in order for the IDE to import the stdlib dependency.
However, it was added to the '*Implementation' configuration, from
where it was also collected for the dependency source set
visibility inference algorithm. The current implementation of source
sets visibility inference only works for module dependencies and is
not quite suitable for local file dependencies. The implementation
should likely be fixed, but for now, it's enough to add the dependency
directly to the place where the visibility inference results are
taken from by the IDE during import, i.e. to the
'*ImplementationDependenciesMetadata' configurations.
Also, since all tests were flawed by the leakin K/N stdlib, the
K2Metadata/Klib compiler mistakenly didn't include its own built-ins
to the module dependencies (and everything worked because the K/N
built-ins were there). Now that the K/N doesn't leak, the compiler
must add its own built-ins.
Refactor the Kotlin/Native compilations and tasks to support
Kotlin/Native-shared source sets compilation within the metadata target.
Provide the feature flag kotlin.mpp.enableCommonKlibs that enables
the following behavior:
* compilation of Kotlin/Native-shared source sets to a klib using
the Kotlin/Native compiler.
* compilation of common source sets (not just Kotlin/Native) into a
klib rather than *.kotlin_metadata
Issue #KT-32677 Fixed
ProhibitInvisibleAbstractMethodsInSuperclasses &
ProhibitNonReifiedArraysAsReifiedTypeArguments were implemented in
1.3.70, so actually they should be enabled only in 1.5
* It enables subtyping relationship for keys and elements, allowing type-safe and concise manipulations on the context when complex hierarchies of elements (e.g. implementors of ContinuationInterceptor) are present
* It unblocks possibility to implement suspendCancellableCoroutine in stdlib
* Implementing proper polymorphic get and minusKey in AbstractCoroutineContextElement is impossible because it will introduce source-incompatible change
* ContinuationInterceptor get and minusKey are adjusted in a completely backwards-compatible way
Added container builders for lists, sets, and maps.
The new experimental type inference only works for the simple builders
with a single generic type. The versions with nullability and the maps
still require explicit specification of the types. Obviously explicit
specification is required for all users who are not using the new
experimental inference. Improving the type inference is something that
should be done separately and many things – including these builders –
will benefit from it, however, this is not a blocker for these builders
in my opinion.
Only supports uncached findViewById/findFragmentById for now; other
features are experimental and the cache only affects performance, so
this should probably be fine for testing Android apps with -Xuse-ir.
Callable reference is "adapted" if it requires some adaptation to an
expected function type - e.g., when a reference to
```
fun foo(vararg xs: Int): Int
```
is used where `(Int, Int, Int) -> Int` is expected.
For such callable references we generate the following IR (in
pseudo-Kotlin):
```
{
fun foo'(p0: Int, p1: Int, p2: Int): Int {
return [| foo(p0, p1, p2) |]
}
::foo'
}
```
where `[| foo(p0, p1, p2) |]` is calling function `foo` with arguments
`p0`, `p1`, and `p2`, as they were mapped by callable reference
resolution.
Dmitry Savvinov