due to a missing mechanism to handle a case when LA succeeds while
codegen fails. See detailed comment in the source.
Fixes implicit conversion test introduced in the previous commit.
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>
Review: https://jetbrains.team/p/kt/reviews/8401
In scope of: KT-55082
Because this version isn't used for anything. We have KotlinAbiVersion
to version the IR format.
Basically, some package names were Native-specific, whilst the packages
themselves were not Native-specific at all. This was already reflected
in the directory layout, but not in the package names.
This is fixed here.
NFC, just an automatic rename of packages with fixes of imports.
When serializing metadata for local delegated properties, we need to
find a valid container class where to put it, and where kotlin-reflect
will be able to find that metadata at runtime. Taking just the closest
class lexically doesn't work, because in the attached test, it is a
class for a lambda which does not have metadata and thus does not have a
way to store any extra information.
So, in 1663619606 we started to look for the closest "non-synthetic"
class to store this metadata. But apparently it was missed that script
is a valid container class. In the test, this meant that no
non-synthetic container classes were found to store the metadata, so we
falled back to using the closest class anyway (see `?: this` in
`rememberLocalProperty`), which turned out to be the lambda.
After this change, metadata for local delegated property in a lambda
will be stored in the script class, just like it's stored in the file
class in the non-script case.
#KT-55065 Fixed
Second step for KT-52615
Get rid of PsiHandlingMode
Get rid of source in FirLazyBlock
Refactor lazy creation
Merge-request: KT-MR-7753
Merged-by: Egor Kulikov <Egor.Kulikov@jetbrains.com>
Before, the only way of getting analyzable elements was to create an
analyzable file by using 'createAnalyzableFile()'. So made all utilities
available in 'KtPsiFactory' useless as they delegate to 'createFile()'
that always set the 'doNotAnalyze' flag.
The new behavior is to pass the 'analysisContext' instead if it is
passed to the 'KtPsiFactory' constructor.
The newly appeared API is going to be used in the Kotlin's UAST
implementation.
JS scripting uses the old IR to JS transformer.
The new IR to JS transformer can not be used for
JS scripting out of the box. Patching the new transformer for
JS scripting is potentially dangerous and requires a lot of effort.
Dropping JS scripting and the old IR to JS transformer allows to
refactor and simplify JS BE codebase.
Mads Ager