Motivation of using dispatch receiver type when calculating method owner
was discussed here: https://github.com/JetBrains/kotlin/pull/3054
However, this is incompatible with type erasure of non-reified type
parameters on inlining (which will be done in future). Consider the
code:
```
inline fun <T> f(arr: Array<T>, p: (T) -> Int): Int = p(arr[0])
fun box() = f(arrayOf("abacaba"), String::length)
```
After inlining and erasure, the type of `arr[0]` is `Any`. Thus, when
calculating owner of `String::length` we would have `Any` instead of
`String` if we used dispatch receiver type.
Note, that this change affects bytecode instruction that invokes
method, but does not change which method is being invoked.
Do not check that non-indy-generated lambdas inherit from Lambda,
because when we enable indy lambdas by default, we're also changing the
behavior of non-indy lambdas so that they won't have the Lambda
superclass anymore (see KT-45375). Since this test was added to check
that any annotation disables indy lambda generation, just leave those
lambdas and rely on the CHECK_BYTECODE_TEXT directive to verify that
there are no LambdaMetafactory in the bytecode text.
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
It would be more consistently to prohibit the behavior from the unmuted
test (see KT-52428), but it was decided to postpone the breaking change.
Unfortunately, it didn't work to make a test where for computing
star projections we would need to substitute other type parameters
because effectively, it's not allowed to have SAM conversion when
star projections/wildcard is based on a type parameter which bounds
use other type parameters.
^KT-53552 In progress
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>
... and the corresponding type parameter has a non-trivial (i.e.
non-`Any?`) upper bound.
The best solution here would be to get rid of
`removeExternalProjections` completely, and just use the type of the
argument at the call site, but see KT-52428.
#KT-51868 Fixed
In case there are several proxy functions for indy lambdas in the same
container, its names are "...__proxy", "...__proxy-0", "...__proxy-1",
..., yet before this change, only the first one was sanitized. So if
it's happening inside a constructor, `<init>` was left unrenamed which
led to ClassFormatError.
#KT-52040 Fixed
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.
This filters it out for use in SAM wrapper generation with
invoke-dynamic.
The intrinsic is not actually used for code generation so
it is added to the list of intrinsics that should have been
lowered away before codegen.
^KT-45779 Fixed
vladislav.grechko