This code may be called during status resolution, but
it can also be called during `COMPILER_REQUIRED_ANNOTATIONS`.
In the latter case we can't expand typealiases.
If we do try to expand typealiases if we can,
and leave them unexpanded otherwise, then we
still may have a problem. Consider the
FirBlackBoxCodegenTestGenerated.Reflection.Annotations.Repeatable
.testKotlinAnnotation test.
In this test we get the following cycle:
```
import kotlin.annotation.AnnotationTarget.* // <- requires TYPEALIAS
@SinceKotlin("1.1") // <- requires String
AnnotationTarget.TYPEALIAS
@IntrinsicConstEvaluation // <- fully expanding this requires
fun String.compareTo() // building it
@Target(AnnotationTarget.CONSTRUCTOR) // <- requires
annotation class IntrinsicConstEvaluation // AnnotationTarget
// in general
// The cycle repeats
```
Or in words if the picture isn't clear:
- Transform `import kotlin.annotation.AnnotationTarget.*`
- Find and deserialize class `kotlin/annotation/AnnotationTarget`
- Load the `TYPEALIAS` field
- Load its annotation `@SinceKotlin("1.1")`
- Find and deserialize `kotlin/String` for `"1.1"`
- Load `String.compareTo`
- Load its annotation `kotlin/internal/IntrinsicConstEvaluation`
>>> At this moment the `extractDeprecationAnnotationInfoPerUseSite`
function is called, and ideally we'd want to fullyExpand
`IntrinsicConstEvaluation`
- While calling `toAnnotationClassId` for it, we find and deserialize
`IntrinsicConstEvaluation`
- `IntrinsicConstEvaluation` has `@Target`
- At this moment we find and deserialize `AnnotationTarget` again.
But This time loading `@SinceKotlin("1.1")` succeeds,
because when loading `kotlin/String` we first create the symbol, then
cache it, then call `postCompute`.
It does not happen with `AnnotationTarget`, because it calls
`findAndDeserializeClass` during `createValue`,
not `postCompute`.
- Thus, we have duplicate `AnnotationClass`-es, and they fail in fir2ir
with "symbol is already bound"
We can't move `findAndDeserializeClass` into `postCompute`, because
during this process when we try to access the
already created and cached symbol for `AnnotationTarget`
(with yet empty fir) we are trying to build the declared member scope
by this `symbol.fir`.
This change affects nothing, because @Serializable is checked during
COMPILER_REQUIRED_ANNOTATIONS when typealiases
are not yet resolved, but in case we change something
in the Future and want to support it, we'd have one less problem
`TYPE_MISMATCH` in `throwJLException.fir.kt` appeared,
because in `throw Exn` the type of `Exn` is implicit Unit.
This is red code anyway.
^KT-55181 Fixed
Merge-request: KT-MR-8292
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
This commit means that we will not see K2 DFA warnings until
we explicitly enable them (probably in 1.9.20 or 2.0).
We are going to enable DFA warnings at the moment when
K2/IDE is accessible for external users
- `.ll.kt` test data can be added in cases where LL FIR resolution
legally diverges from K2 compiler results.
- Each `.ll.kt` test is prefixed with an `LL_FIR_DIVERGENCE` directive
which must explain why the test may diverge from K2 compiler results.
- `LLFirDivergenceCommentChecker` ensures that each `.ll.kt` file
contains an `LL_FIR_DIVERGENCE` directive.
- `LLFirIdenticalChecker` results in an assertion error if the `.ll.kt`
test and its base test are completely identical, including in their
meta info (but ignoring `LL_FIR_DIVERGENCE`).
- The checker additionally ensures that the base source file and the
`.ll.kt` source file have identical Kotlin source code (ignoring
meta info and `LL_FIR_DIVERGENCE`). This ensures that both tests
test the exact same thing.
- `.ll.kt` files are ignored by select test generators, in addition to
`.fir.kt` files.
This way inheritors of such class would be able to override category
members the same way they can in Objective-C. Also, API surface of
interop libraries should become a little more stable.
Bogdan Mukvich