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
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
- StackValue already avoid to generate checkcast from a type or an
array to java.lang.Object. Add a new case to avoid to generate a
checkcast from an array to an array of java.lang.Object when arrays
have the same dimensions.
Fix of https://youtrack.jetbrains.com/issue/KT-22714
See the previous commit for information on the kotlin-reflect vs
kotlin-reflect-api distinction.
Add kotlin-reflect as an explicit runtime dependency of most of the test
configurations because even though they all depend on tests-common, the
runtime dependency on kotlin-reflect is not exported from tests-common
to other modules because the projectTests dependency is not transitive.
This allows to get rid of the dependency on descriptors.runtime from
compiler/IDE tests which is problematic: classes there clash with the
classes in kotlin-reflect, which reference declarations in shadowed
packages
`tests-jar` configuration now extends testRuntime instead of testCompile
(note that testRuntime extends testCompile),
and projectTests() dependency shortcut makes it transitive.
This is required to depend on test utility modules producing `-tests` jar instead of default one
without listing all their transitive dependencies.
Effectively, this commit drops cached value for j.l.Object type
This cache was introduced when types were immutable, but they
became mutable after starting reading top-level TYPE_USE annotations,
that lead to changing shared JAVA_LANG_OBJECT_CLASSIFIER_TYPE instance
#KT-20826 Fixed
If there is default qualifier with TYPE_USE closer than one with METHOD
then its nullability should be considered even when enhancing return type
#KT-20016 Fixed
Only top-level types on fields, methods' return types and
value parameters are supported to catch-up how class-files are loaded
in IntelliJ (see IDEA-153093)
NB: this commit also affects
ForeignJava8AnnotationsNoAnnotationInClasspathWithFastClassReadingTestGenerated
that were failing before
#KT-20016 Fixed
- Apply default qualifiers to type arguments if they contain TYPE_USE
in applicability list
- Read TYPE_USE placed default qualifier annotations
#KT-19592 Fixed
#KT-20016 In Progress
Alexander Udalov