The root cause of the problem is that we visit class annotations more
accurately than in the regular compiler transformer, so we have
a difference: the compiler assumes that annotation processing
of the class is called already inside this class, so it should enable
CLASS_HEADER_ANNOTATIONS mode to not capture extra context.
But we in LL FIR do this out of the class, so such context switching
is redundant and results in cutting out the outer class context
^KT-62587 Fixed
Previously, creating a declaration with Fir2IrCallableDeclarationsGenerator/
Fir2IrClassifiersGenerator didn't guarantee that this declaration will
be actually added to the list of parent class/file declarations, which
lead to situations when FIR2IR created some declarations in the air
(mostly fake-overrides)
It is needed to have an ability to distinguish those two cases in FIR2IR:
Without this change the following tests fail:
- org.jetbrains.kotlin.test.runners.codegen.FirPsiBlackBoxCodegenTestGenerated.Enum
- testEnumEntryReferenceFromInnerClassConstructor1()
- testEnumEntryReferenceFromInnerClassConstructor2()
- testEnumEntryReferenceFromInnerClassConstructor3()
- testInnerClassMethodInEnumEntryClass()
- testInnerClassMethodInEnumEntryClass2()
- testKt9711_2()
- testDeepInnerClassInEnumEntryClass()
- testKt7257_boundReference1()
- testInnerClassInEnumEntryClass()
- testKt44744_innerClass()
For reasoning refer to the message of the previous commit
It is the same as for `getIrFunctionSymbol`
There is one failing test here, caused by KT-61941
The issue was here before this commit, but it was hidden
It's incorrect to create fake-overrides with `getOrCreateIrFunction/Property`
call. FakeOverrideGenerator should be used instead. So this commit
just changes the place which creates static f/o generated from
I failed to reproduce the corresponding failure in compiler tests, but
without this change FP Kotlin test fails
Previously `getIrFunctionSymbol` effectively did the same thing as `getOrCreateIrFunction`,
but in a slightly different way. To avoid logic duplication and source of
potential inconsistencies, implementation was changed to just delegate to
`getOrCreateIrFunction`
Changes in `computeIrOrigin` were required because origin for callables in
`getOrCreateIrFunction` and `getIrFunctionSymbol` was computed differently,
so `computeIrOrigin` was changed to preserve existing behavior
^KT-60924
https://youtrack.jetbrains.com/issue/KT-59916/K2-Disappeared-REPEATEDANNOTATION
FirAnnotationChecker does not detect repeated annotation on dynamic type, since FirTypeResolverImpl wrongly did not convert source annotations to attributes of ConeDynamicType.
This MR improves FirTypeResolverImpl to convert attributes of FirDynamicTypeRef to annotations and attach them to ConeDynamicType.
Merge-request: KT-MR-12551
Merged-by: Vladimir Sukharev <Vladimir.Sukharev@jetbrains.com>
This flag will be used on JVM to determine whether or not to generate
external enum entries mappings ("$EntriesMappings") classes. Note that
from the frontend's point of view, every enum has `entries`, so for
backend purposes we have to reach out to the underlying deserialized
data to read the flag from the metadata.
The enumEntriesIntrinsicMultipleEnums.kt test was supposed to check that
JVM backend generates 3 `$EntriesIntrinsicMappings` classes: for X, for
Y, and for Z. Mappings classes are generated for enums without
`entries`, i.e. Kotlin enums compiled without `EnumEntries` language
feature, and Java enums. The test incorrectly _enabled_ the language
feature for X though, and `$EntriesIntrinsicMappings` for X was
generated anyway because of KT-61208.
To keep the original intention of the test, I'm disabling the language
feature for X, so that it will be considered as enum without `entries`.
KT-61208 will be fixed in a separate commit (with separate tests).
The boxInline and bytecodeText tests changed their meaning when language
feature EnumEntries started to be enabled by default, so those changes
are a continuation to ebd43fc8c0. The behavior did not change after
enabling the feature, once again because of KT-61208.
Also, remove obsolete error suppressions which are no longer needed
after 64c8ce18a0.
It's effectively a breaking change (^KT-62558)
K2 assigns flexible type to all static fields (from Java) and, for example,
`String? becomes String unlike K1. It affects IR signature generating.
That's why signature dump is disabled for some tests.
^KT-57811 Fixed
^KT-61786 Fixed
Such properties should be stateless and just wrap over accessories.
Logic inside contract transformer is unreachable because we do not
allow lazy resolution for synthetic properties.
^KT-61990
See the comment in the code for more info.
No proper test added because the compiler test infrastructure lacks the
ability to run old compiler versions, however I've verified manually
that the change fixes the issue.
#KT-62531 Fixed
Reporting of those errors was implemented as an ad-hock solution for part
of the KT-58881, and it was implemented incorrectly. There won't be any
need in this reporting in actualizer after KT-58881 will be fixed, so
there is no actual sense to fix their implementation in actualizer itself
(as it will be removed)
In Kotlin subclasses of `MutableCollection<Int>`, the method
`remove(Int)` has its argument boxed, so that it wouldn't clash with the
method from `java.util.List`. So `JavaOverrideChecker` should understand
that a Java method `boolean remove(java.lang.Integer)` overrides it,
otherwise platform declaration clash was reported.
The code is adapted from `forceSingleValueParameterBoxing` in K1's
`methodSignatureMapping.kt`.
The test has been moved and adapted from diagnostic to codegen box
tests, to check correct backend execution + runtime.
#KT-62316 Fixed
Unresolved annotation arguments were treated as absent arguments,
which lead to false-positive reports.
Add assert and test for that and fix.
MR: KT-MR-12245
^KT-60671 Fixed
This includes checking of annotatins set on:
- value parameter types
- type parameter bound types
- extension functions receiver types
- function return types
- class super types
Fix in `defaultParams_inheritanceByDelegation_positive.kt`
is needed because of problem in resolution of implicit return types
(KT-62064), which leads to crash in annotation checker, because it
expects resolved return type.
MR: KT-MR-12245
^KT-60671 Fixed
Dmitriy Novozhilov