It basically can be replaced with IR interpreter. The only half-hack
was required in `PropertyReferenceLowering`. Const interpreter is
running before it, so we can't optimize some calls on const
properties that appear after this lowering. Solution is to inline
constants manually during property reference lowering.
Cases when default argument inhertied from super class are allowed.
Some tests for default arguments already exist and can be found in
`testData/diagnostics/tests/multiplatform/defaultArguments`, for example
`annotationsViaActualTypeAlias.kt`.
^KT-57614 Fixed
Merge-request: KT-MR-10356
Merged-by: Roman Efremov <Roman.Efremov@jetbrains.com>
The tests are removed because JvmDefault is going to be deprecated with
error in KT-54746 and removed later in KT-57696.
Many of the removed tests already had existing counterparts with the new
modes `all` and `all-compatibility`. In this change, I've added such
tests where they were missing, and removed tests which were testing
behavior specific to the JvmDefault annotation, such as some
diagnostics.
#KT-54746
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>
- The fix for KT-55570 caused some backend tests to fail, because errors
are now correctly reported for simple classes and actual/expect in
the same module is not supported in FIR. See KT-55177.
- The commit also adds separate tests for K2. Unfortunately, these have
to be disabled for K1 because K1 then reports "expect without actual"
errors.
It's anyway safe to use avoidComprehensiveCheck = true because
during deserialization we're sure that we need DNN type because
it's been serialized as such.
We need to supply signatures for private declarations even when their
containing file is not known. In situations where the FirDeclaration in
question is already known (i.e. where we are never going to serach for
the declaation based on that signature), FirDeclaration itself is
sufficient as a key.
Always serialize type table (and version requirement table) after
everything else, to prevent bugs like KT-51446 where inline class
underlying type was added to the type table after it has already been
serialized.
#KT-51446 Fixed
The inliner uses module descriptors to figure out if it needs to
regenerate objects.
We should avoid the use of descriptors in the inliner, but this
works as a first quick fix.
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.
Prefer to have all module dependencies, including dependencies on
stdlib/reflect, declared explicitly. This allows to have tests on
situations like the one in KT-45308: three modules A<-B<-C, where C
doesn't depend on A, which was compiling correctly with the old JVM
backend before 1.5, but started to fail with JVM IR in 1.5.
Also simplify the code a bit, remove duplicated logic.
This will be used at least in the JVM backend instead of the current
approach where we're loading the primary constructor's first parameter,
which isn't good enough since primary constructor can be private, and
we can't rely on private declarations in case they're declared in
another module.
Vladimir Sukharev