Backend: If kotlin class extends kotlin.collection.List
write it as it's super interface (light class mode only)
IDE: Provide wrapper classes to java resolve
that try to emulate backend behaviour
For example if kotlin class implements kotlin.collections.Map,
we provide a superinterface that has abstract 'getEntries' method
and 'entrySet' method that is considered default.
In reality all those methods are generated in the class itself.
In IDE supporting this case without hacks is not feasible performance-wise
since kotlin.collection.* may not be an immediate supertype and we need
to compute all supertypes just to calculate own methods of the class
Allow to get annotation list and to invoke `findAnnotation` without building delegate
Introduce KtLightNullabilityAnnotation which holds nullability information and is built
before delegate is built
Otherwise any cached reference to light class can lead to severe memory leaks in IDE
since LightClassBuiderResult holds GenerationState which holds ModuleDescriptor
Class APIs from java point of view stays the same so we can avoid generating those methods
Otherwise we have to calculate all supertypes when getMethods() is called,
which imposes severe performance penalties
We have to pretend these methods are not 'abstract' (also we consider them 'default' for safety)
so java highlighting does not report "class should be abstract" for all inheritors
We have to manually report "class should be abstract" on some of the java inheritors,
specifically those that are implementing interfaces directly
as opposed to extending kotlin classes implementing those interfaces
Replace `takeIf { !expr }` with `takeUnless { expr }`.
Cleanup redundant parethesis as in `listOf((expr))`.
Replace `listOf(expr)` with `expr.let(::listOf)` where the former caused significant indentation change.
Step 0: Light class object is created, no delegates are computed
Step 1: constructs dummy delegate which can not be relied upon to know signature of any member
It can be used to construct light field and light method objects
(which can correctly respond to some queries) before constructing real delegate
Step 2:
Construct real delegate if dummy delegate is not enough to respond to a query
This speeds up multiple scenarios where getMethods() and getFields() are called on numerous classes
Dummy delegate's faster consruction is achieved by using specially setup dumb analysis instead of ide analysis
Introduce LazyLightClassDataHolder: which manages creation of Step 1 and Step 2 delegates
Introduce MemberIndex: keeping track of member creation order, helps matching light class delegates created in different contexts
KtLightMethod and Field: make use of dummy delegate
KtLightMethod no longer extends LightMethod since it requires eager delegate construction
KtLightMethod now implements PsiAnnotationMethod for convenience (ClsMethodImpl implements PsiAnnotationMethod)
Introduce LightClassDataHolder: which now is reponsible for constructing clsDelegate
Move out light big chunk of delegate building logic out of LightClassDataProvider into LightClassBuilder
LightClassData only holds information about single class
Pavel V. Talanov