After this change, optional expected annotations will be compiled to
physical class files on JVM, and stored to metadata on other platforms,
to allow their usages from dependent platform modules. For example:
@OptionalExpectation
expect annotation class A
When compiling this code on JVM, A.class will be produced as if the
class A did neither have the 'expect' modifier, nor had it been
annotated with OptionalExpectation. Note that if there's no actual
annotation class for A, then usages (which can only be usages as
annotation entries) are simply skipped.
Class A will be public from Kotlin's point of view (since it should
be possible to use it in Kotlin sources), but _package-private_ in Java
to disallow its usages outside of the declaring module.
#KT-18882 Fixed
#KT-24617 Fixed
Previously, inline suspend functions were effectively inline only,
but ordinary inline functions can be used as noinline.
To fix the issue, I generate two functions: one for inline with suffix
$$forInline and without state machine; and the other one without any
suffix and state machine for direct calls.
This change does not affect effectively inline only suspend functions,
i.e. functions with reified generics, annotated with @InlineOnly
annotation and functions with crossinline parameters.
#KT-20219: Fixed
This commits adds a new annotation OptionalExpectation to the standard
library, which is experimental. To enable its usage, either pass
'-Xuse-experimental=kotlin.ExperimentalMultiplatform' as a compiler
argument, or '-Xuse-experimental=kotlin.Experimental' and also annotate
each usage with `@UseExperimental(ExperimentalMultiplatform::class)`
#KT-18882 Fixed
Introduce COMMON_COROUTINES_TEST directive.
Every test with this directive is run twice: one time with
language version 1.2 and kotlin.coroutines.experimental package
and the other time with language version 1.3 and kotlin.coroutines
package. Each run is a separate method: with suffixes _1_2 and _1_3
respectively.
However, since codegen of release coroutines is not supported in JS
backend, we generate only one method: with suffix _1_2.
#KT-23362
Generate continuation type as kotlin.coroutines.Continuaion. This code will
fail at runtime since there is no stdlib backing this change yet.
However, in order to generate compatible stdlib we need a compiler, which
generates continuation type as kotlin.coroutines.Continuation.
Thus, firstly we support the change in the compiler, make it bootstrap
compiler and only then change stdlib and tests accordingly.
#KT-23362
Private suspend functions need to be generated as package-local, since
they are called from their continuations.
However, this means that they can be called from Java, which breaks
their private visibility.
Adding synthetic to them fixes the issue.
#KT-17584: Fixed
Sometimes instead of {POP, GETSTATIC Unit.INSTANCE, ARETURN} sequence
the codegen emits {CHECKCAST Unit, ARETURN} sequence, which breaks tail
call optimization. By replacing CHECKCAST with ARETURN we eliminate
this issue.
#KT-19790: Fixed
Design decision: if the field for a companion object should have
non-public visibility, generate it with @Deprecated annotation in
language version 1.2.
TODO: generate it with proper visibility in 1.3 and later.
KT-11567 Companion object INSTANCE field more visible than companion object class itself
These changes has been introduced in c3a032ea0b
to support new scheme for named functions
At the same time they can be avoided by generating some additional
code/accessors in the anonymous classes for coroutine state
Now we cannot simply remove introduced API because of bootstrap problems
#KT-17898 Fixed
The main idea is to leave all the inline functions as is, without
state machines (but keeping suspend-calls markers) and
determine whether we need a state machine from the bytecode
after inlining into a non-inline function
#KT-17585 In Progress
#KT-16603 In Progress
#KT-16448 Fixed
Since annotations are a part of the declaration, they must have the same
visibility as the declaration in the bytecode. Otherwise obfuscators like
Proguard might strip the "$annotations" method and no annotations would be
found via Kotlin reflection
#KT-15993 Fixed
Otherwise it breaks JPS assumptions, that leads to exceptions like:
Error:Kotlin: [Internal Error] java.lang.AssertionError: Couldn't load KotlinClass from /Users/jetbrains/IdeaProjects/KotlinPlaygroundBeta11/out/production/KotlinPlaygroundBeta11/Counter$both$1.class; it may happen because class doesn't have valid Kotlin annotations
at org.jetbrains.kotlin.build.GeneratedJvmClass.<init>(generatedFiles.kt:36)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.getGeneratedFiles(KotlinBuilder.kt:469)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.doBuild(KotlinBuilder.kt:241)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.build(KotlinBuilder.kt:140)
...
