The main change here is in `JvmInlineClassLowering.visitFunctionAccess`,
where we now store the substituted return type of the function as the
type of the call expression. Without it, the call could have a
meaningless type, e.g. some `T` which is inaccessible at that place, and
that could backfire in subsequent lowerings in codegen. For example, in
the `stringPlus.kt` test, it would prevent the code in
`FlattenStringConcatenationLowering.isStringPlusCall` from recognizing
and replacing the `String.plus` call, leading to a codegen exception.
Other changes are mostly cosmetics to make the code similar to
`visitFunctionReference`, and preventive optimizations for the case when
the substitution map is empty.
The inline class is boxed when we pass it as lambda argument, now we
unbox it. If the underlying type is not Any or Any?, bridge method does
the unboxing.
#KT-32450 Fixed
#KT-39923 Fixed
#KT-32228 Fixed
#KT-40282 Fixed
In 1.3.x, for inline class member inline vals 'getFoo-impl' method was
generated in corresponding inline class.
Since 1.4.0, getters for properties returning inline class values are
mangled (so corresponding getters are named 'getFoo-<mangling_hash>'.
However, to maintain backward compatibility with libraries compiled with
1.3.x, inliner should be able to find 'getFoo-impl' method in the
bytecode.
Don't mangled functions annotated with @JvmName.
Annotate 'Result.success' and 'Result.failure' with @JvmName and
@Suppress("INAPPLICABLE_JVM_NAME").
NB this would require bootstrap.
Fix for test data (inlineFunctionInsideInlineClassesBox.kt) is needed
to avoid check about "no inline functions".
This check has two steps: first, names of inline functions from
the metadata are loaded, then these names are checked that they are
presented for physical methods in the classfile.
Because now there are no physical methods in the classfile, we can't pass
the second check, therefore this fix is needed.
#KT-24872 Fixed
Alexander Udalov