This flag was added a long time ago, at the time when we weren't sure if
we were going to keep the naming of local and anonymous classes
completely equal to the naming in the old backend. Now that we've
decided that we won't keep it equal and there are a lot of differences
already, it's not useful anymore.
Report a separate error when class files compiled with FIR are in
dependencies, in addition to the one for class files compiled with FE
1.0 + JVM IR.
#KT-43592
Introduce an enum DeserializedContainerAbiStability with two values.
This is needed in order to support another reason for ABI instability in
a subsequent commit, namely "unstable because compiled by FIR".
#KT-43592
All of new classes lays in lays in :compiler:tests-common-new module
which includes classes for FE 1.0 and FIR diagnostics tests and
JVM black boxtests
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
Iaroslav Postovalov