`LightElementValue` made PsiCompiledElement to make it properly anchorable when creating smartpointers, when still use `kotlinOrigin.containingFile` for it to be able to `registerProblem` on such elements. (refs KT-18054)
When getting annotations for KtLightParameter which is property parameter we should return annotations for parameter instead of property
#KT-19671 Fixed
Previous implementation worked through equality that used equality
of method stubs (see LightMemberOriginForCompiledMethod). But method
stubs for compiled element can be recreated when caches are outdated,
including weak reference cleaning (see ClsJavaStubByVirtualFileCache).
This could cause misbehave of find usages when java reference has an
outdated version of light element in resolution cache.
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
Alexander Podkhalyuzin