An overridden abstract member with a more specific "return type" than an overridden concrete member
should be explicitly overridden even if the class in question can have abstract members.
Previously we inferred "open" if there was at least one open member in the
hierarchy. However, that's not correct when that member is overridden by
another member in the hierarchy which is abstract. This led to incorrect code
being accepted by the front-end, and an exception during the bridge generation
#KT-12467 Fixed
Previously the code was operating under the assumption that if the
implementation of some function (both the implementation and the function come
from supertypes) does not have a proper return type (the one which is a subtype
of return type of all declarations of this function in the supertypes), then
there's necessarily at least one abstract declaration of the function, such
that the implementation's return type is not a subtype of the return type of
that declaration. The assertion makes sense when the hierarchy above the
current class does not have any errors: we should report at least one function
as being "not implemented" in the current class.
However, as demonstrated by the test case, if there's an error already in the
supertypes with regard to overridability of members, this assertion may be
wrong. Reporting the "not implemented" error in such case is in fact not
necessary because of the already existing error ("return type mismatch" in the
test) in the supertypes
#KT-12482 Fixed
It helps to get rid of semantics duplicating and fixes known bugs
- SOE in OnlyAbstractMethodFinder.find
- type enhancement for SAM constructors
#KT-11287 Fixed
#KT-11322 Fixed
EA-77989 Fixed
Given overridden descriptors D = d[i].
1. Find D*, subset of D:
returnType(d* from D*) <: returnType(d) for each d from D.
Always prefer var to val.
2. Prefer non-flexible return type to flexible.
Check for var/val overrides properly
(NB: this will report PROPERTY_TYPE_MISMATCH_ON_OVERRIDE
for all properties, not just overrides involving vars as it was before).
- Tests.
- No need for a separate diagnostic message regarding
return/property type conflict on override by delegation:
it is always a conflict of inherited signatures.
Overridden signatures should have compatible return types
(equal types for 'var').
Only relevant overrides should be taken into account.
Refactor inherited signatures check,
introduce a strategy interface for problem reporting.
- base class method wins against a (default) interface method,
so an abstract base class method should always be implemented
in a derived class;
- interface methods clash regardless of abstract/default
with possibly undefined behavior at run-time,
so a class or interface should always define its own method
for methods inherited from multiple interfaces and not from base class;
- meaningful diagnostics for class inheriting conflicting JVM signatures.
Since no override will happen under Java 8 rules,
ACCIDENTAL_OVERRIDE is misleading for this case;
- update testData.
Dmitry Petrov