<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.
Suspend functions and callable references to suspend lambdas are already
supported.
Support callSuspendBy of suspend function of big arity.
#KT-24854: Fixed
Avoid name clashes in cases such as
inline class Login(val login: String)
inline class Password(val password: String)
fun validate(login: Login) { ... }
fun validate(password: Password) { ... }
Same as for primitives: inline lambda expects to see a boxed value,
so, even if an argument is a local variable, it can't be remapped,
because it contains unboxed representation.
Arguments are put on stack in the direct order, and then stored into
local variables for inlining in the reversed order:
<arg0>
<arg1>
<arg2>
store <param2>
store <param1>
store <param0>
Original value parameter types were taken in direct order, though.
When we have a nullable inline class value with non-null underlying
type, corresponding value in unboxed representation is nullable. E.g.:
inline class Str(val value: String)
fun test(s: Str?) = listOf(s)
Here 'test(s: Str?)' accepts nullable 'java.lang.String' as a parameter.
When boxing/unboxing nullable values of such inline classes, take care
of nulls.
#KT-26052 Fixed Target versions 1.3-M2
* Move FinallyBlockLowering to common part
* Fix catching of dynamic exception
* Fix bridges for suspend functions
* Disable explicit cast to Unit
* Run lowering per module
* Update some test data
Dmitry Petrov