* Fix objects in inline functions and lambdas:
* Add common lowerings used in K/JS and K/Native
* Fix inline lambda call detection logic in presence of additional casts
Merge-request: KT-MR-8791
Merged-by: Svyatoslav Kuzmich <svyatoslav.kuzmich@jetbrains.com>
This inconsistency is present due to not using the `// WITH_STDLIB`
in the above tests. When K1 creates the enum, it tries to generate
`entries()`, and for that it tries to load `kotlin.enums.EnumEntries`,
but this is actually an unresolved reference. K1 silently swallows it,
and proceeds.
The reason K2 doesn't fail is that in order to generate `entries()` it
simply creates the necessary `ConeClassLikeType` with the desired
`classId` instead of loading the whole `ClassDescriptor`.
The reason we can still observe `$ENTRIES` and `$entries` in K1
is because they are generated during the JVM codegen, and it
only checks if the `EnumEntries` language feature is supported. It
doesn't check if the `entries` property has really existed in IR
(by this time it's expected to have already been lowered to the
`get-entries` function - that's why "has ... existed").
The reason why the codegen doesn't fail when working with
`kotlin.enums.EnumEntries` is because it creates its
own `IrClassSymbol`.
^KT-55840 Fixed
Merge-request: KT-MR-8727
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Ensure that when .entries is accessed from an inline function body
or lambda argument, EntriesMapping are properly generated and used
without excessive mappings and duplicated fields
#KT-53236
This is what Java 15+ does, and it permits accessing captured type
parameters via reflection. The alternative is to emit generic signatures
on the lambda methods, but that was disabled and I have no clue why.
^KT-52417 Fixed
This is godugly code, where a flag for file level signatures is passsed
around.
An alternative would be not to create file level signatures for toplevel
private clases, since those still need unique names, at least on JVM.
But that would break binary compatibility.
Signatures are due for overhaul anyway. Hopefully this code can be
reverted at that point.
`$$forInline` functions do not pass through the state machine generator,
and optimizing `Ref`s before that changes how assignments inside lambdas
passed to `suspendCoroutine`, etc. behave: without a `Ref`, the
assignment is not reflected in the continuation object, so the variable
has old value on resumption.
These functions will be optimized later, after they are inlined
somewhere and the state machine is generated.
^KT-52198 Fixed
If a lambda expression does not capture any local variables, convert
it to a global free function and replace the lambda creation with
a reference to that function.
Example: for the following Kotlin code
```kotlin
fun foo(f: () -> Unit) = f()
fun bar() = foo { console.log("hello") }
```
before this patch, we generated:
```js
function foo(f) {
return f();
}
function bar() {
return foo(bar$lambda());
}
function bar$lambda() {
return function () {
console.log('hello');
};
}
```
after this patch, we generate:
```js
function foo(f) {
return f();
}
function bar() {
return foo(bar$lambda);
}
function bar$lambda() {
console.log('hello');
}
```
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
Igor Chevdar