This fixes the problem in JVM IR backend which didn't pass bound
receiver value of an adapted function reference to the superclass
(kotlin/jvm/internal/AdaptedFunctionReference), which caused equals to
work incorrectly on such references (see changes in box tests).
Previously, bound adapted function reference was represented as
IrFunctionExpression to an adapter function which calls the callee. The
value of the bound receiver in that case could only be found in the body
of that adapter function. This is not very convenient, so this change
makes psi2ir produce a block of the adapter function + reference to it.
The bound receiver value is then found in the reference. This is
basically similar to what ProvisionalFunctionExpressionLowering is doing
for all function expressions. And since this IR structure is already
supported in FunctionReferenceLowering, the problem in the JVM IR is
fixed without any additional modifications.
However, inliners do not support this IR structure yet, see KT-38535 and
KT-38536.
This allows removing a hack in the MethodSignatureMapper.
When introducing non-getter methods that dispatch to a getter
we have to be careful to use the right name.
DeepCopyIrTreeWithSymbols should create the link between new
properties and their new getter/setter.
Currently DescriptorByIdSignatureFinder performs lookup of descriptor
not only in the given module but also in its dependencies.
This behaviour is incorrect if we have some kind of
relation (e.g. mapping) between moduleDescriptor and found descriptor.
Thus, we add a handle to control search scope.
- Introduce Ir-based Functional interface factory
- Switch from LazyIr to pure
- Use kotlin library to access raw bytes
- Link dirty files against IC cache and dependencies instead of LazyIr
- Move `DescriptorByIdSignatureFinder` from K/N to common
- Support inline-bodies only MODE
Before this change, deserialized scopes were not tracking lookups properly,
because lookup tracker was not passed from compiler configuration correctly.
Because of that, lookups from dependencies were not tracked,
so multi-module IC was not working (chages were passed between modules,
but affected source files were not invalidated).
It's used as a superclass for anonymous classes for adapted function
references. Its main feature is that it _doesn't_ inherit from KFunction
(as opposed to FunctionReference), as per the decision to postpone
reflection support for adapted function references in KT-36024.
#KT-36024 Fixed
Otherwise, the generated bytecode is unnecessarily suboptimal in some
(arguably weird) cases.
In the JVM backend, this was an accidental regression in #3260, as I had
not noticed that effectively inline-only functions were handled by a
separate branch in FunctionCodegen. In JVM_IR, I'm pretty sure the
redundant markers have always been there as `isSuspensionPoint` in
ExpressionCodegen never checked for effectively-inline-only-ness.
Dmitry Petrov