One might think that it shouldn't be run because of 'if (declaration
!is KtNamedDeclaration) return' check in the 'check'-overload.
However, for default accessors we pass PSI for property, i.e.
KtProperty (see 'DeclarationCheckers.checkAccessors'), which
obviously passes this check
Note that we can't use `DescriptorToSourceUtils` here, because it's
returns `KtProperty` for default accessor too.
This commits adds specific check for that case, to avoid exception in
KT-28385. Ideal solution would be to either don't launch checkers on
such parameters, or explicitly declare semantic of the
'declaration'-parameter, e.g. to rename it to 'reportOn' (see KT-28403
for discussion)
^KT-28385 Fixed
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
The call to `createTopLevel` instead of `create` (which creates
serializers for outer classes properly, with correct type parameter
contexts) caused MetadataSerializer to write type parameter metadata
incorrectly. For example, in the following case:
class A<E> {
inner class B<T, E> { ... }
}
A's type parameter E would get id 0, and B's type parameters T and E
would get ids 0 and 1. This is a problem because ids are supposed to be
unique for each class including its outer classes, and deserializer,
decompiler and stub builder rely on this assumption.
JVM metadata is unaffected because `create` is called correctly there,
see MemberCodegen#generateKotlinClassMetadataAnnotation
#KT-24944 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
When default argument value was present in the expected declaration, we
did not correctly serialize that fact to the metadata for the actual
declaration (`declaresDefaultValue` was used). Therefore, it was
impossible to use that actual declaration without passing all parameter
values in another module, where it was seen as a deserialized descriptor
#KT-21913
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
Divide incompatibility on two groups: strong and weak. Strong incompatibility means that if declaration with such incompatibility has no `actual` modifier then it's considered as usual overload and we'll not report any error on it.
#KT-20540 Fixed
#KT-20680 Fixed
Note that the quick fix to implement header class works incorrectly when
that class has nested classes at the moment; this should be fixed
separately
#KT-15494 Fixed
#KT-18573 Fixed
Also support a quick fix to add 'impl' modifier (KT-18454), although it
doesn't work yet on classes because there's no error on them in the IDE
#KT-18087 Fixed
#KT-18452 Fixed
#KT-18454
Try to report most of the errors on the actual members of the impl
class. In many cases, there's a 1:1 mapping of header to impl class
members, so the error "some members are not implemented" on the class
declaration itself is redundant. Exceptions include functions/properties
from supertypes (there may be no other place to report a signature
mismatch error in this case), functions/properties not marked with
'impl' (the checker is only run for declarations explicitly marked with
'impl') and default constructors (the checker is not run for them)
#KT-18447 Fixed
Try to report most mismatch errors on the 'impl' declaration. Only
report a mismatch error on the 'header' declaration if no error would be
otherwise reported on any 'impl' declaration in the compilation unit.
Also render declaration kind in the message
#KT-18447 In Progress
Also, require users of K2MetadataCompiler to pass "-Xmulti-platform"
manually. Gradle and Maven plugins already do that, so only users who
invoke kotlinc directly are going to be affected by this
#KT-19287 Fixed
In the test case, the problem was that Foo.a's type was resolved to the
_class A_, which was written to metadata on JVM instead of the class
AImpl with typealias A as an abbreviation. This metadata was incorrect
because there's no class A from the JVM compiler's point of view; that's
why the error "cannot access class A" was reported
#KT-19151 Fixed
This fixes KT-17001 because now 'header' modifier is loaded correctly
for deserialized members and the standard disambiguation in
OverloadingConflictResolver.compareCallsByUsedArguments takes place,
where header members are discriminated against the corresponding impl
members
#KT-17001 Fixed
Similarly to getFirstClassifierDiscriminateHeaders, we select the first
non-header class if possible, otherwise we select just the first class.
This makes sure that a reference will never be resolved to a header
class if the corresponding impl class is present.
Note that overall the issue may not be fixed yet, because there are
other scopes where header classes are not yet discriminated
(LazyImportScope, DeserializedMemberScope). However, at this point I
cannot reproduce this problem with these other scopes
#KT-15521 Fixed
