There's still some blind spots:
- Covariant overrides in Java (KT-25036)
- Current implementation assumes that when language version is 1.3 every suspend function
reference only release-coroutines-package Continuation
(we need to check if it's a correct statement)
#KT-24848 Fixed
#KT-25036 Open
Before this change, kotlin.suspend was being loaded as having a common
function type instead of suspend function type.
With LV=1.3, we expect that suspend function types should have
new Continuation interface as a last type argument, while
kotlin.suspend is built with LV=1.2 and has old Continuation.
This change might be reverted once stdlib will be rebuilt with LV=1.3
NB: kotlin.suspend doesn't need to be intrinsified since it only returns
its parameter with checkcast to kotlinin.jvm.functions.Function1
(i.e., it doesn't refer the coroutines package)
#KT-24861 Fixed
Namely, check that when one calls a restricted function
the reciever used for that calls is obtained exactly from the enclosing
suspend function
#KT-24859 Fixed
if assertions mode is not LEGACY.
This is done since assertions can be disabled (in both compile time and
runtime) and thus, the data flow info is not reliable anymore.
#KT-24529: Fixed
If a declaration is annotated both with SinceKotlin and WasExperimental
and the SinceKotlin version makes it inaccessible, the experimental
checker must regard it as experimental, with markers specified in the
WasExperimental annotation arguments. So only errors/warnings about the
experimentality are going to be reported in this case, and no error that
the declaration is unavailable because of a low API version
For example, if a class is `@SinceKotlin("X")
@WasExperimental(M::class)`, then its constructor should also be
accessible if API < X, provided that the opt-in to M is given
Experimental and UseExperimental can only be used as annotations or
qualifiers (to allow "Experimental.Level.*"); experimental markers can
only be used as annotations or qualifiers, or as left-hand side of a
::class literal in arguments to UseExperimental/WasExperimental.
This is needed because we're not yet sure of the design of this feature
and would like to retain the possibility to drop these declarations
(Experimental, UseExperimental) altogether. If they were going to be
used as types, it would be problematic because we can't simply delete
something from stdlib, should deprecate it first. With this change,
these declarations can only be used if the user has opted into using the
experimental API somehow (for example, with
`-Xuse-experimental=kotlin.Experimental`), so we won't stop conforming
to our deprecation policy if we decide to remove these declarations in
the future
Usages of declarations annotated with WasExperimental are allowed even
if the API version requirement is not satisfied, provided that the
opt-in to all mentioned markers is given. This is needed for smooth
graduation of API in kotlin-stdlib
Since we're not yet sure of the design of Experimental/UseExperimental,
we're making them "experimental" themselves in some sense, in that the
user is required to provide the magic argument
"-Xuse-experimental=kotlin.Experimental" to be allowed to use either
Experimental or UseExperimental. This is more convenient than the
previous approach of "-language-version 1.3
-Xskip-metadata-version-check" because it's simpler and does not cause
pre-release binaries to be produced
See https://github.com/Kotlin/KEEP/issues/95#issuecomment-383889404
Drop Experimental.changesMayBreak, Experimental.Impact, the concept of
signature/body usage, same module exemption. Make the majority of tests
single-module because there is now no difference in the checker between
usages from the same module or from another module
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
Condition was too strict
if @JvmDefault implicitly hidden by class in inheritance.
Diagnostic is redundant cause there isn't breaking
change depending on interface method generation strategy and
delegating stub generation in inheriting class.
Condition was too strict if we actually make super call
through super class. Diagnostic is redundant cause there isn't breaking
change depending on interface method generation strategy.
Treat them like lambdas. This means:
1) Like local suspend lambdas, which become "non-suspend" after creating
jvmSuspendView, they do this as well
2) They both are generated with the same codegen.
3) They are treated differently only on front-end side.
#KT-20364: Fixed
Use fake continuation instead of ALOAD 0 while inlining
Do not generate state machine for inner lambdas and inner objects,
which capture crossinline suspend lambda.
#KT-19159: Fixed
Probably, it would be more correct to skip such lambdas when resolving
the returns' references, but it'd be more complicated and still useless
since non-local returns are impossible in such lambdas
(relevant parameter is noinline)
#KT-22900 Fixed
This test checks that a usage inside an annotation argument is a
signature usage, which may be too restricting but easier to support at
the moment (and the restriction can be lifted in the future)
This results in more diagnostics usually, but allows library authors to
avoid annotating everything in each experimental class with the marker
(only the class needs to be annotated now)
#KT-22759
Denis Zharkov