Note that previously we implicitly ignored JS_IR backend when directive
COMMON_COROUTINES_TEST was enabled, see kotlin/generators/util/coroutines.kt#L57
Both for callables obtained via reflection API (KClass.members etc) and
for callables obtained via ::-references, the instance parameter is now
the class which was used to construct the type at the left-hand side of
the reference, NOT the class where the callable is originally declared
as is known at compile-time. The reason is to reduce the difference in
behavior of KCallable.call vs FunctionN.invoke: the latter always
required the subclass instance for a fake override, and it's reasonable
that the former would require it as well.
Note that in Java reflection, behavior could differ in a similar case.
For a simple fake override, Class.getMethod would return the method
declared in the base class and that method will accept instances of the
base class in invoke. However, it's difficult to rely on this behavior
because if there's a bridge for a fake override in the derived class
(e.g. when overridden members have different signatures), the returned
Method object is accepting the derived class as the receiver. This just
confirms the fact that Java reflection operates on a different level of
abstraction, namely JVM methods in .class files, which is not applicable
to our use cases directly. Another reason not to replicate Java
reflection's behavior is the uncertainty as to which member is returned
in case there are several in the hierarchy for a given fake override:
see the "otherwise one of the methods is chosen arbitrarily" note in
javadoc on Class.getMethod.
#KT-24170 Fixed
It's difficult to fix KT-22818 until the IR comes along, so we're
providing a workaround where one can disable the
ACTUAL_FUNCTION_WITH_DEFAULT_ARGUMENTS error and provide default values
in the actual function, to avoid exception from the backend.
#KT-22818
When we've determined that we are going to invoke an erased inline class
method ('static foo-impl(this, ...)' in inline class), keep track of it
so that the remaining type mapping logic proceeds correctly.
#KT-26998 Fixed Target versions 1.3.20
When mapping callable method signature for erased inline class methods,
use original function descriptor instead of super declaration
(otherwise it would map to a default interface method with mismatching
signature).
When generating delegates to Kotlin default interface methods, keep
track of the original Kotlin types for delegating method arguments and
interface method arguments.
'original' for value parameters of fake overrides points to the
overridden function value parameters instead of the value parameter of
the unsubstituted function. This causes inconsistent type mapping for
inline classes implementing generic interfaces with default methods.
#KT-25295 Fixed Target versions 1.3.20
#KT-26931 Fixed Target versions 1.3.20
In MemberDeserializer.loadProperty, we incorrectly passed 0 to
getAnnotations when loading annotations on property accessors in case
the protobuf field getter_flags/setter_flags was not present. The
correct behavior, as described in metadata.proto, was to pass a special
"default accessor flags" value, constructed from the main property
flags. Otherwise in case there were annotations both on the property and
on the accessor (as in PropertyAndAccessor.kt) and the accessor was
otherwise default, we would assume that it had no annotations and would
not load them in compiler and reflection
#KT-25499 In Progress
<IMPL_SUFFIX> for method is a method signature hash,
if method value parameter types contain inline class types,
otherwise 'impl'.
Constructor methods are named as 'constructor-<IMPL_SUFFIX>'.
Synthesized 'box' and 'unbox' methods are named as
'<METHOD_NAME>-<IMPL_SUFFIX>'.
Erased implementations of overriding and non-overriding methods
are named as '<METHOD_NAME>-<IMPL_SUFFIX>'.
Fully specialized implementation of 'equals' will have a special suffix.
Consider an import from an inline function invocation. If it is
being called from another inline function, it should be defined
in a special way (e.g. `$$importsForInline$$.foo`) so that
the compiler knows where to load transitive dependencies from.
What's more, the declaration itself should be inside the inline
function wrapper.
Otherwise it should be defined in a regular way (e.g.
`$module$bar.foo` among other top-level imports).
By default the imports are loaded in the first form, and
transformed into the second one when needed. To check
whether this transformation the following predicate is
used: `inlineFunctionDepth == 0`.
At the moment the mentioned variable is increased upon
visiting an inline function declaration (`defineInlineFunction`),
and upon visiting an unknown (not visited before) inline function invocation.
It seems that instead the variable should be increased when processing
an existing inline function wrapper. At that point a new place to
put import definitions (`statementContextForInline`) is set.
Due to way JS code is generated (lambda's come before their call sites)
this issue seems to have been masked. Primary class constructors are a special
case - they come before any other declaration within. Hence a lambda
invocation inside a constructor leads to incorrect import definition.
We might want to add 'init' blocks later, so now, for the sake of
binary compatibility with 1.3-RC binaries, we have to generate these
'constructor' calls.
Note that in some tests inline class boxing is no longer redundant,
because resulting value is passed to 'constructor' as an argument.
Dmitry Petrov