Consider the code below
```
fun test() {
a@ b@ {
{}
}
}
```
Currently when the code is converted to FIR, label `b` is bound to the
outer lambda and `a` gets bound to the inner lambda because it's not
consumed. This is wrong and also leads transfromation to fail with
exceptions because of the unexpected consumption of `a`.
This change fixes the above issue by designating a specific node in the
AST as the allowed user of a label when the label is added.
They may or may not be inlined later.
IDK how the test passes when both modules are compiled with the old
backend - perhaps this has something to do with the fact that when `f`
is compiled with the IR backend, the call to `x()` is followed by `pop`
and `getstatic kotlin/Unit.INSTANCE`? This is probably why the original
issue in kotlinx.coroutines reports that everything works fine with
kotlinx-coroutines-core:1.4.3.
^KT-46879 Fixed
^KT-48801 Fixed
The condition on the relationship between the current class and the type
of the receiver for protected members was the opposite of what the JVMS
says, and yet somehow mostly worked?
#KT-48331 Fixed
#KT-20542 Fixed
1. throw goes to catches instead of main exist block
2. return goes via finally (single level only supported atm)
3. collect non-direct return to retrieve all return expressions easier
Seperate checker for platforms that do not support this language feature yet
Synthetic implementations of annotations are generated on-demand with proper
equals, hashCode, and annotationType methods
#KT-47699 Fixed
The type of the default lambda may be a subtype of the parameter type,
so we can't really generate our own coercions at all as we don't know
the precise Kotlin type of the `invoke` method.
Crossinline lambdas *can* be inlined into objects, but don't *have* to;
the correct place should be determined from the context, not from the
parameter.
This is needed for the inliner: since the information about Kotlin type
of the bound receiver is nowhere in the output binary, the inliner will
have no clue how to box inline class values. Moving the boxing outside
the object means the inliner doesn't need to know about it; from its
point of view, the captured value has type `Any`.
Mads Ager