This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
* 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>
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.
Note that KT-30696 is fixed only in the single-module case, and KT-42012
is not fixed fully (see KT-44855).
#KT-30041
#KT-30629
#KT-30696
#KT-30933
#KT-32351
#KT-32749
#KT-38849
#KT-42012
#KT-42990
#KT-44234
#KT-44529
#KT-44631
#KT-44647
Before this commit, during the resolve of companion objects we used
the same context than for any nested class. However, during companion
object resolve we should not have companion object receiver itself
accessible in any case (in particular, it should not be accessible
in constructor). So in this commit we introduced separate context
for this purpose.
Before this commit, we sometimes tried to fetch anonymous object by id,
getting sometimes a wrong result because it's singleton.
Now we use lookupTag or FIR class itself instead.
#KT-44050 Fixed
vladislav.grechko