- Split it into two functions getAllOverriddenSymbols and getDirectlyOverriddenSymbols
- Implement tests for getOverriddenSymbols
- temporary mute inheritance.kt light classes test
Using "JVM_1_8" always resulted in incorrect mapping of Kotlin
annotation targets to Java element types.
The change in AbstractKotlinRenderLogTest is needed because while
CliTraceHolder.module is technically a descriptor leak, it was never
detected by this test accidentally, because of the depth cutoff equal to
10, which started to not be enough after the minor refactoring of
replacing `Delegates.notNull` with `lateinit`.
Add visibility modifier to companion field
Const initializer is now getting for const properties only
Fixed tests:
UltraLightClassLoadingTestGenerated.testAnnotations
UltraLightClassLoadingTestGenerated.testInheritance
UltraLightClassLoadingTestGenerated.testProperties
UltraLightClassSanityTestGenerated.IdeRegression.testImplementingMutableSet
UltraLightClassSanityTestGenerated.IdeRegression.testOverridingFinalInternal_extra
UltraLightClassSanityTestGenerated.IdeRegression.testOverridingInternal
UltraLightClassSanityTestGenerated.IdeRegression.testOverridingInternal_extra
UltraLightClassSanityTestGenerated.IdeRegression.testOverridingProtected_extra
UltraLightFacadeClassTestGenerated.testProperties
UltraLightClassLoadingTestGenerated.testObjects
Remove INSTANCE field for local object declarations
Remove private suspend functions create from UL
Add correct extension function parameter name
Add support for setparam annotation modifier
It helps to generate properly the annotations for delegates
Also note in test, that annotations in Base class have really weird
text of arguments and also don't have names
KtLightNullabilityAnnotation is specifically designed for old light classes
and includes a bunch of hacks that are applicable for them
So, we have to introduce own hack into it
(see org.jetbrains.kotlin.asJava.classes.KtUltraLightParameter#getTypeForNullability)
that is a bit of hard to support when extending hierarchy
It's necessary because after next changes,
they become different for ultra and old light classes.
The former (ultra) is more correct but it doesn't help when
we need to compare our implementation with reference
When trying to estimate if annotation entry might be resolved
to a specified fqName we should track the short name from entry itself
instead of the short name of desired annotation
There's no need to add "values"/"valueOf" methods for them
(see com.intellij.psi.impl.compiled.StubBuildingVisitor#visitMethod that ignores them too)
We already have tests that check enum entries/synthetic methods
are properly resolved in Java:
idea/testData/kotlinAndJavaChecker/javaAgainstKotlin/*Enum*
Igor Yakovlev