... if the delegate happens to be a function call whose second
argument is a callable reference but not actually a provideDelegate
call.
The fix is to ensure that the call is _actually_ a desugared
provideDelegate call.
This fixes a CCE in a case where the delegate expression is a regular
function call and the second argument is a callable reference.
#KT-65165 Fixed
We can omit `get` call to delegated property and inline
constant value directly. If we are not going to
do that, we can get a runtime exception because
all usages of const property will be inlined and the property
itself will be dropped.
#KT-63567 Fixed
#KT-63580 Fixed
See the comment at updateSubstitutedMemberIfReceiverContainsTypeVariable
It became necessary after delegate inference is rewritten, since before
that happened, stub types were being left there and FIR2IR handled
them accidentally properly because stub types are equal to anything.
But that wasn't really correct even there because stub types are not
intended to leak out of the FIR
^KT-61060
The main idea is getting rid of stub types and using just type variables
See more detailed description at docs/fir/delegated_property_inference.md
The problem with stub types is that they need really special treatment
in many places, and on the other hand, there are no clear contracts on
how they should work (that regularly leads to bugs like KT-59529)
^KT-61060 Fixed
^KT-61075 Fixed
^KT-61077 Fixed
^KT-59529 Fixed
^KT-61633 Related
^KT-61618 Related
^KT-61740 Related
^KT-59107 Related
^KT-61747 Related
^KT-61077 Related
^KT-61781 Related
Add some more filters on private/synthetic stuff (which doesn't matter
in practice) to make full and light analysis mode dumps as similar as
possible, so that all existing tests will pass for JVM IR. Unmute some
tests which were failing with the old JVM backend.
Tests on repeatable annotations are muted because in full analysis,
annotations are wrapped into the container (e.g. `@A(1) @A(2)` ->
`@A$Container(A(1), A(2))`), but they are no in the light analysis mode.
So there's always going to be a difference for these tests between full
and light analysis, unless we're going to change behavior of kapt, which
would be a kind of a breaking change.
#KT-58497 Fixed
To make these tests behave closer to kapt, since kapt is the primary use
case for the light analysis mode.
AbstractLightAnalysisModeTest compares the text dump of bytecode
obtained with full analysis and light analysis, removing things like
anonymous/synthetic entities. In the light analysis mode anonymous
objects in supertypes are always approximated, and in the full analysis
mode they are always present as is in signatures. So we're transforming
the text dump in the same way, by approximating anonymous objects in
signatures (more precisely, in return types of methods and fields) to
the supertype.
Java declarations do not have a file parent, their outer element is
IrExternalPackageFragment.
The test did not fail in K1 only by accident, because there's an extra
IrTypeOperatorCall on the property reference's dispatch receiver, which
automatically makes it non-inlinable. In K2, it's IrGetField, so we were
trying to compute if its dispatch receiver is inlinable and for that we
tried to get its fileParent, which resulted in exception if it comes
from Java.
Also refactor PropertyReferenceDelegationTransformer.canInline a bit.
#KT-57955 Fixed
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@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>
For negative case, throwing CCE, we already have the issue KT-8135
and dedicated tests:
* genericDelegateUncheckedCast1.kt
* genericDelegateUncheckedCast2.kt
Related issues: KT-8135 KT-39588 KT-48749 KT-49837
For properties which delegate to other property via the getValue
operator from stdlib (see KT-39054), we generate `$receiver` field which
stores the receiver of the property reference used in the delegate. The
problem was that this backing field was missing `correspondingProperty`.
It's needed because it is used as a map key to store static fields in
`JvmCachedDeclarations.getStaticBackingField`. If it's null, accesses to
the static $receiver fields are not remapped correctly in
`RemapObjectFieldAccesses` and
`MoveOrCopyCompanionObjectFieldsLowering`, which led to ICCE or NSFE.
#KT-49793 Fixed
Vladimir Sukharev