The type of the default lambda may be a subtype of the parameter type,
so we can't really generate our own coercions at all as we don't know
the precise Kotlin type of the `invoke` method.
This is needed for the inliner: since the information about Kotlin type
of the bound receiver is nowhere in the output binary, the inliner will
have no clue how to box inline class values. Moving the boxing outside
the object means the inliner doesn't need to know about it; from its
point of view, the captured value has type `Any`.
Old compiler versions still won't be able to load default lambdas
generated by JVM_IR, but this way we avoid incorrect behavior of
function references taking inline class types that unbox to Any.
#KT-46601 Fixed
In general case parameter type could differ from actual default lambda type.
E.g.: fun inlineFun(s: (Child) -> Base = { a: Base -> a as Child}),
where type of default lambda is '(Base) -> Child'.
In such case we should find somehow actual invoke method in bytecode knowing
only name, number of parameters and that's actual invoke is non-synthetic
regardless of bridge one.
#KT-21946 Fixed
pyos