* introduced KtLightIdentifierBase so that both FIR LC and ULC share
basic implementations
* detach PsiCompiledElement as per KTIJ-21412,
while introducing KtLightIdentifierWithOrigin so that
UastLightIdentifier can still inherit origin computation logic
^KTIJ-21412 In Progress
'ClsClassImpl' instances created by the platform contain synthetic
enum methods (added by 'ClassInnerStuffCache.calcMethods()'). Such
convention is common in IntelliJ (see KT-36095 and
'9a8b345adaded83fe13980a28db5d9f9acc7450d' in the IntelliJ repository).
This commit makes Kotlin's stub-based classes consistent with the
convention. Instead, a filter is added in place of 'ClsClassImpl' usage.
See also the following commits:
- 7c86911f44
- 43468c6d55
'KotlinClassInnerStuffCache' was copy-pasted from the platform's
'ClassInnerStuffCache' several years ago. After J2K and other changes,
it became quite dirty.
Besides cleaning things up, enum synthetic method handling have
significantly improved. Before, such methods were handled only in
'processDeclarationsInEnum', and 'getMethods()' didn't return them.
This led to inconsistent behavior and was reason for providing special
ad-hoc support in '1b6ded600518176b21cc308ed3e032ef8d04cc90'.
All the other annotation classes has abstract modifier.
All nested interfaces has static modifiers.
This commit is not so important for compiler, but it is matter for IDE,
because when we load classes in IDE via
KtLightClassForDecompiledDeclaration -- there are Abstract and Static
on the Container class
FIR LC has a different abstraction, so using the specific class name is
literally too specific to FE 1.0 LC.
We could introduce a common interface for those, but checking
`kotlinOrigin` is good enough, and thus type-checking their common
ancestor is good enough too.
enum class, which is extended by enum entries, should not be final.
(Those enum entries should be, instead.)
enum class itself wouldn't be instantiated, and thus it's technically
abstract, but having a private ctor() would be an option.
For the latter case, we can simply put no modality modifier.
Example of such class declaration would be `10 < class A` expression
The expression is uncompilable, but parsable. Unfortunately, the
FIR compiler does not save `class A` reference in it (because it
is not an expression, and only an expression can be a LHS or RHS of
binary expression `10 < ...`)
When we try to build light classes, we will try to find/build FIR
declaration for this class, but we won't be able to, and this will throw
an error
Adding this check should fix few
`FirKotlinHighlightingPassTestGenerated$Regression` tests
Nicolay Mitropolsky