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
If we do, the local variable table will not make sense. As as
example:
```
inline fun foo(getString: () -> String = { "OK" }) {
println(getString())
}
inline fun bar() {
}
fun main() {
bar()
foo()
}
```
leads to the following bytecode:
```
public static final void main();
descriptor: ()V
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
Code:
stack=2, locals=4, args_size=0
0: iconst_0
1: istore_0
2: nop
3: nop
4: iconst_0
5: istore_1
6: nop
7: ldc #53 // String OK
9: astore_2
10: iconst_0
11: istore_3
12: getstatic #30 // Field java/lang/System.out:Ljava/io/PrintStream;
15: aload_2
16: invokevirtual #36 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
19: nop
20: return
LineNumberTable:
line 9: 0
line 13: 2
line 10: 3
line 14: 4
line 15: 6
line 16: 7
line 17: 19
line 11: 20
LocalVariableTable:
Start Length Slot Name Signature
2 1 0 $i$f$bar I
6 14 1 $i$f$foo I
4 16 0 getString$iv Lkotlin/jvm/functions/Function0;
```
The `getString$iv` local should not be there. It has been inlined away.
Leaving it in the local variable table leads to inconsistent locals
info. Local 0 contains an int but we declare a local of type
Function0.
In cases when the test has the JVM_TARGET directive, use that one for
Java compilation as well.
Otherwise, for box tests, the corresponding test in `JvmTarget6OnJvm6`
(module `:compiler:tests-different-jdk`) will fail. However, it affects
all codegen tests, so fix a bunch of them which use Java 8+ features to
explicitly compile with JVM target 1.8. In particular, this obsoletes
the SKIP_JDK6 directive in those tests because "JVM_TARGET: 1.8" also
skips it for JDK 6.
The check for IS_SOURCE_6_STILL_SUPPORTED is needed in order to still be
able to run tests in the project while only having a single JDK > 11
installed, and having all of the env vars JDK_16, JDK_17, JDK_18
pointing to that JDK.
Previously helpers from checkType.kt was in special package, and
if directive was enabled then test runner (`AbstractDiagnosticTest`)
injected additional imports to test files and removed them after test
was completed.
It's very hard to support such behavior in new test infrastructure so
there was a decision about changing `CHECK_TYPE`:
1. All helpers from `checkType.kt` now stays in default package
2. `CHECK_TYPE` only adds `checkType.kt` to set of analyzed files
and don't modify their content
For test which are written in default package (most of tests actually)
there are no changes. On the other hand if there is a test where dev
want to use checkType functions in testfile with some package then he
should explicitly import functions which he needed (`checkSubtype`,
`checkType`, `_`)
This helps to reduce peak memory in lowerings/codegen by a lot.
A more robust approach would be to have a separate BindingContext for
each file, and clear each of them after running psi2ir on it. This would
also lower peak memory usage in psi2ir.
Provide a fallback workaround compiler argument
-Xir-do-not-clear-binding-context just in case BindingContext is in fact
used somewhere and it's not caught by tests.
Dmitry Petrov