Use `// !LANGUAGE: -ReleaseCoroutines` instead in tests which require
old (1.2) coroutines, and nothing in tests which require new coroutines
because master is already 1.3. Also remove superfluous API_VERSION and
other directives which have no effect anymore. Do not include runtime
automatically with `WITH_COROUTINES`/`COMMON_COROUTINES_TEST` in box
tests; require `WITH_RUNTIME` for that (majority of tests already had it
anyway), but remove it from bytecode text tests where runtime is always
added automatically. Fix the coroutine package selection code in
KotlinTestUtils and update the bunch files correspondingly.
Disable tests in `box/coroutines/noStdLib` on JVM: despite the name,
these tests were launched with stdlib because of the code in
CodegenTestCase, and they do not work without it because at least
CoroutineUtil.kt requires stdlib to compile correctly
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
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
This patch mutes the following test categories:
* Tests with java dependencies (System class,
java stdlib, jvm-oriented annotations etc).
* Coroutines tests.
* Reflection tests.
* Tests with an inheritance from the standard
collections.
Basically they're built upon basic coroutine tests, but for each of them
different interceptResume implementation are injected
(currently there are 12 of them).
It might be more simple just to generated additional testData, but I see this
more problematic in a sense of further maintenance
Note that all tests add idempotent 'interceptRun' operators,
which just execute given lambda in the current thread
#KT-14891 Fixed
