During extracting type attributes from annotations we should expand
typealiases of annotation type to handle cases when user makes a typealias
on some special annotation, like `kotlin.internal.Exact`. And to exapnd
typealias we should resolve annotation class id to symbol.
This leads to a cycle during class deserialization, if some nested annotation
is used as type annotation in some declaration in the same class
```
interface SomeInterface {
interface NestedInterface : @Ann Some
interface Some
@Target(AnnotationTarget.TYPE)
annotation class Ann
}
```
Attempt to find symbol for SomeInterface.Ann during deserialization of
SomeInterface.NestedInterface wil lead to second attempt to deserialize
class SomeInterface, which eventually leads to StackOverFlow. And at the
same time expanding typealiases for annotations from binaries has not
much sense, because types in binaries are already expanded
So to fix this issue it's enough to just not expand typealiases on type
annotations for types of deserialized declarations
^KT-57876 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>
If an annotation doesn't specify an explicit use-site target,
previously it was added to both, the primary constructor value parameter
and the property in the FIR. Then, in FIR2IR, only the "correct" one was
added to the IR. Move up the deduplication logic into the frontend.
^KT-56177 Fixed
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>
In K1 analogue of `K2_VISIBILITY_ERROR` is `K1_RUNTIME_ERROR`, so
candidates with `K2_VISIBILITY_ERROR` should win over innaplicable
candidates with `INAPPLICABLE`, `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
or `INAPPLICABLE_WRONG_RECEIVER` applicability
This is needed to allow resolution to invisible symbols (and later
suppress error with `@Suppress("INVISIBLE_SYMBOL", "INVISIBLE_REFERENCE")`
^KT-55026 Fixed
^KT-55234
Test data in `box/annotations/typeAnnotations` is changed because nested
classes in type annotations are rendered differently in JDK 19
(`Outer.Nested` instead of `Outer$Nested`).
#KT-54116 Fixed
For non-suspend lambdas annotations are carried over to the
invoke method so that tooling can find the annotation there.
It seems reasonable that annotations are carried over to
the invokeSuspend method on suspend lambdas as well so that
similar tooling can be built and work for suspend lambdas.
This directive makes the test standalone, i.e. disables grouping it with
other tests into a single compilation, and in particular disables
package renaming for the test.
Also, remove the old hard-coded way to mark tests standalone.
so that defaults are available to synthetic implementations.
#KT-48181 Fixed
Implementation is for JVM IR; other backends & FIR need to be supported
separately.
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.
This shows up in annotation instantiation tests where we need
to make sure to generate a property on the annotation implementation
class for such properties.
It won't fix KT-48181 completely, but it will allow to create such annotations
if all value arguments are specified.
For the full fix, we need to read default annotation values from classfiles in jar.
#KT-48181 In progress
Ivan Kylchik