including varargs, apparently.
So, we allow unsigned types and unsigned arrays in annotations,
but disallow user-defined inline classes.
#KT-23816 Fixed
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.
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.
[JS IR] Move tests into compiler/testData
[JS IR] Add cyclic dependencies with lazy property initialization
[JS IR] Add test on not initialization in case of call non properties (classed, objects, enum classes, const vals)
[JS IR] Add initialization through top level
[JS IR] Ignore enum getInstance function in property lazy initialization
[JS IR] Use let function with useful result instead of pure apply and also
[JS IR] Remove duplicated tests in js.translator
Otherwise, information about members moved from companion objects to the
parent class (e.g. on JVM, companion object fields -> static fields in
parent class) will be incorrect.
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
1. When an annotation has multiple targets, the priority goes like this:
constructor parameter (if applicable) -> property -> backing field.
2. The argument to `kotlin.annotation.Target` is a vararg, so that
should be handled as well.
3. `AnnotationTarget.VALUE_PARAMETER` allows receivers, constructor
parameters, and setter parameters, while `AnnotationTarget.FIELD` allows
both backing fields and delegates.
Known issue: java.lang.annotation.Target is not remapped to the Kotlin
equivalent, so things are still broken for pure Java annotations.
Ilmir Usmanov