Get rid of all classes except kotlin.reflect.KFunction, which will be used to
represent all kinds of simple functions.
Lots of changes to test data are related to the fact that KFunction is not an
extension function (as opposed to KMemberFunction and KExtensionFunction who
were) and so a member or an extension function reference now requires all
arguments be passed to it in the parentheses, including receivers. This is
probably temporary until we support calling any function both as a free
function and as an extension. In JS, functions and extension functions are not
interchangeable, so tests on this behavior are removed until this is supported
@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
#KT-2095 Fixed
fix backend-side issues with kotlin.jvm.overloads: support the annotation on constructors, generate nullablity annotations on parameters, generate generic signatures, add various tests
There is a lot of changes about closures calculating and generating.
1. As classes can have more than one constructor each of them should
have closure arguments.
2. Captured variables set is the same for all of them.
3. Within constructors bodies/delegating calls closure parameters
should be accessed through method arguments because fields may be
not initialized yet.
The main problem of the previous approach was that we were only generating
erased method signatures, which was incorrect in case a class also had a member
from another supertype with the same signature as the substituted one from the
collection. Javac issues compilation errors when compiling Java code against
such classes.
Also all the needed method stub signatures were hardcoded in
generateBuiltInMethodStubs() and the case of MutableListIterator was missing
SAM-related code in codegen was using JavaClassDescriptor directly, which has
an erased signature. Create and use a new abstraction SamType which has a full
generic signature of a type which was used in the SAM construct
"context.contextKind()" was incorrect in
ExpressionCodegen.intermediateValueForProperty(), because it represents the
context of the call site, not the context of the property declaration
#KT-4878 Fixed