The existing backend restores LVs and parameters from the suspend lambda
fields used for spilling between suspension points, hence they are
visible in the debugger as local variables, plain and simple.
This PR introduces the same pattern to the IR backend, to bring the
debugging experience in line with the existing backend.
Both backends are still at the mercy of the liveness analysis
performed in the coroutine transformer where a liveness analysis
minimizes live ranges of entries in the LVT. E.g. an unused parameter
will be dropped entirely.
Adjusted existing test expectations accounting for the differences in
LV behavior.
The current backend uses direct field access to the backing field
instead of calling the companion object accessor, which calls
an accessibility bridge, which then gets the field for code such as:
```
class A {
companion object {
val s: String = "OK"
}
// f uses direct access to the A.s backing field.
fun f() = s
}
```
This change does the same for the IR backend.
The problem is that JvmRecord has SOURCE retention
Probably, increasing its retention might be a more reliable solution
(or in some other way serializing that the class is a record)
Just checking supertypes seems like a reasonable approximation:
only records kotlin are allowed to extend j.l.Record.
But the relevant diagnostic has been added only since 1.4.30,
so potentially there could have been exist a non-record class with
such supertype compiled by 1.4.20, but this case seems to be ill-formed
and marginal anyway.
For Java classes, it's irrelevant since they don't have member properties
(only synthetic extensions)
^KT-43677 In Progress
Instead, check that origin of the parent class is DEFAULT_IMPLS. Also,
add a separate origin SUPER_INTERFACE_METHOD_BRIDGE for interface
methods with bodies that are copied to classes.
It was only used to generate deprecation in codegen, but it's annotated
with `javaLangDeprecatedConstructorWithDeprecatedFlag`, and a similar
annotation for IrField results in ACC_DEPRECATED. Adapt codegen to
generate this flag for functions too.
References to properties with JvmStatic getter were not handled in
MakeCallsStatic (by overwriting dispatchReceiver with null) because the
property itself was not considered static.
#KT-43672 Fixed
... in case `-Xno-optimized-callable-references` is enabled. Before this
change, the generated abstract equals/hashCode methods were considered
as accidental overrides because they did not have equals/hashCode from
the supertype in the overriddenSymbols list.
#KT-43666 Fixed
This allows to get rid of the situation where a JvmStatic function in
object can be seen in different states in different lowerings: unlowered
with a dispatch receiver parameter, declaration is lowered but calls are
not, and both declaration and calls are lowered.
Now it works like this:
1) JvmStatic functions in objects coming from dependencies are always
loaded as lowered, without the extra dispatch receiver parameter. In
psi2ir this is done via JVM-specific extension; in fir2ir it's done
in place (but probably should be extracted to extension too).
2) Functions from sources are created as unlowered by both psi2ir and
fir2ir, and are lowered in a module-wide phase at the beginning of
JvmLower.
3) Calls to all JvmStatic functions from objects (from sources and
dependencies) are lowered in the same phase at the beginning of
JvmLower.
This ensures that all lowerings after the module-wide phase
`jvmStaticInObjectPhase`, which include all per-file phases, see all
JvmStatic functions in objects without the additional dispatch receiver
parameter, and calls do not have dispatch receiver either.
The only issue with this approach is that function/property reference
representation in reflection needs to have that dispatch receiver
parameter, and that is achieved via a hack in those lowerings, which
seems not too out of place anyway, given that they're handled specially
in kotlin-reflect as well.
Allow to replace "this" references not only inside IrBody, but inside
any IrElement. This will be useful in JvmStatic in object lowering where
we want not only to replace usages inside the function body, but also in
default values of its parameters.
Dmitry Petrov