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
Use "-Xno-check-impl" to suppress checking whether the platform declaration
implementation has the "impl" modifier.
Do not check presence of fake overrides from platform class in the impl class,
otherwise there would be a lot of errors about the fact that
equals/hashCode/toString are not marked with the "impl" modifier
When matching platform and impl classifiers, ensure that each declaration from
the platform class scope is present in the impl class scope.
Note that the presence of the 'impl' modifier is not checked yet
For each platform declaration, there must be at least one impl declaration in
the module with the compatible signature; similarly, for each impl declaration,
there must be at least one platform declaration with the compatible signature.
Note that currently the presence of the 'impl' modifier is not checked yet.
Also, the sad fact is that if you have platform and impl declarations which are
not compatible, you get two errors: on the platform delcaration and on the impl
declaration. This needs to be addressed as well
Alexander Udalov