Without this, the unrelated type specified on the LHS of a property reference
literal was considered to be an extension receiver of the candidate, and the
resolution was erroneously successul. This is only reproducible for properties,
because if we're trying to resolve an extension, we consider all properties
from the scope, even non-extensions, because there may be a property of an
extension-functional type (T.() -> R). (We don't do this for functions.)
#KT-7430 Fixed
#KT-7945 Fixed
Implemented unqualified 'super' type resolution (in BasicExpressionTypingVisitor).
No overload resolution of any kind is involved.
Corresponding supertype is determined by the expected member name only:
- 'super.foo(...)' - function or property (of possibly callable type) 'foo'
- 'super.x' - property 'x'
Supertype should provide a non-abstract implementation of such member.
As a fall-back solution for diagnostics purposes, consider supertypes with abstract implementation of such member.
Diagnostics:
- AMBIGUOUS_SUPER on 'super', if multiple possible supertypes are available;
- ABSTRACT_SUPER_CALL on selector expression, if the only available implementation is abstract.
#KT-5963 Fixed
For each non-abstract non-declared (i.e. inherited from supertypes) method in
an interface we generate its static form to the TImpl, which calls the TImpl
method from the corresponding supertype.
The accidental override tests changed because we're now trying to generate the
delegate for the super method, not knowing that it will clash with the declared
method
#KT-2888 Fixed
#KT-5393 Fixed
For example,
KMemberFunction2<T, P1, P2, R> : KMemberFunction<T, R>
So for this inheritance the heuristic that was present ("take the last K type
parameters of the subclass, and substitute for K parameters of the superclass")
was wrong. The new heuristic for this case is: take type parameters with the
same names.
Also don't store "parameters" in a lazy value, since it's easy to compute and
it's computed practically every time anyway
@platformName is now supported for final non-overriding class member functions
(including property accessors).
Front-end provides diagnostics for inapplicable annotation cases.
Code generation updated:
- ignore kotlin.platform.platformName annotation for Java class methods;
- bridges generation generates proper JVM declarations in case of methods renamed with @platformName.
@platformName-related tests added.
#KT-5524 Fixed
Users' Java code will not break in common cases (when passing functions to
Kotlin), and deprecation warnings will be reported.
Provide an inspection with a quick fix which allows to replace deprecated
function class usages to the new classes. Include this fix to the "code
cleanup" action
Alexander Udalov