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.
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.
[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
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.
if it is called using parens and not by calling 'invoke' method.
Use underlying type when calling continuation constructor if suspend
function is method inside inline class.
#KT-43505 Fixed
#KT-39437 Fixed
inside 'create' if 'create' overrides 'create' from
BaseContinuationImpl. In other words, unbox the parameter if 'create'
accepts only one parameter.
#KT-43249 Fixed
#KT-43533 Fixed
inside 'invoke' if 'create' does not override 'create' from
BaseContinuationImpl. In other words, when suspend lambda accepts more
than one parameter (including receiver).
Do that only if we do not generate bridge 'invoke' method, since
inline classes are unboxed in the bridge.
Use mangled name for 'create' function in this case inside 'invoke'.
#KT-43249 In progress
#KT-39847 Fixed
#KT-38937 Fixed
Dmitry Petrov