When a parameter has a default argument value both in the expected
annotation and in the actual annotation, they must be equal. This check
has been only implemented for the case when actual annotation is Kotlin
source code, and NOT a Java class coming from an actual typealias. The
latter case would require a bit more work in passing a platform-specific
annotation-value-reading component to ExpectedActualDeclarationChecker,
and is therefore postponed.
For now, Java annotations that are visible through actual type aliases
cannot have default argument values for parameters which already have
default values in the expected annotation declaration
#KT-22703 Fixed
#KT-22704 Open
The point is that it's placed in module 'resolution' where it can be
accessed for example in ArgumentsToParametersMapper to load default
argument values from expected function
'hasDefaultValue' needs to be adapted to support locating default values
in 'expect' functions, and this is not possible in module 'descriptors',
where it was originally declared. Therefore, move it to module
'resolution' and copy its current logic to a separate function
'declaresOrInheritsDefaultValue' which is used in 5 places.
'hasDefaultValue' itself is updated in subsequent commits.
Besides changing imports, also use a simpler declaresDefaultValue in
some places, which does not include default values inherited from
supertypes: this is OK for constructors, and in LazyJavaClassMemberScope
for functions from built-ins which do not have default argument values
at all
Also make TypeParameterUpperBounds a "strong" incompatibility, meaning
that non-actual members from platform module are _not_ going to be
matched to the expected members if this incompatibility exists between
them, and therefore NO_ACTUAL_FOR_EXPECT will be reported on the
expected declaration, instead of ACTUAL_MISSING on the platform member.
This is needed because the difference in type parameter upper bounds can
have effect on the function signature on the platform (e.g. on JVM,
Array<T> -> T[], but Array<T> -> Comparable[] if T : Comparable<T>), and
it would be incorrect to report ACTUAL_MISSING on the member that has
nothing to do with the expected declaration that happens to coincide
with it in everything except type parameter bounds
#KT-21864 Fixed
This fixes `VerifyError` for all integration tests calling
`KotlinTestUtils.findAndroidSdk()`.
The exception was thrown because `:kotlin-gradle-plugin-integration-tests`
was depending on both relocated intellij-core (from kotlin-compiler-embeddable)
and non-relocated intellij-core (transitevely through tests jars from compiler).
A call to `findAndroidSdk()` was triggering classloading
for `KotlinTestUtils` which had bytecode references to
`org.jetbrains.kotlin.idea.KotlinLanguage` loaded from the embeddable compiler
and to `com.intellij.lang.Language` loaded from non-relocated intellij-core.
`KotlinLanguage` from the embeddable compiler was a subclass of relocated
`org.jetbrains.kotlin.com.intellij.lang.Language` thus it was not
assignable to `com.intellij.lang.Language` causing `VerifyError`.
The solution is to create relocated jar combining the necessary test jars
from the compiler.
A test task, that uses android dependency but does not depend on
a corresponding configuration, would fail when it was run after
'clean' task.
I've extracted 'useAndroidSdk', 'useAndroidJar' extensions
making it harder for a developer to forget to set up task dependencies.
Pavel V. Talanov