multiple unnamed arguments represented as value named expression with array initializer
call kind for array in annotation argument should be "array initializer" instead of "method call"
#KT-16600 Fixed Target Versions 1.1.5
When getting annotations for KtLightParameter which is property parameter we should return annotations for parameter instead of property
#KT-19671 Fixed
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
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)
It also affects working with KotlinChangeLocalityDetector. Right after error is fixed in local context file is still reported as having errors and diagnostics are not counted.
#KT-12022 Fixed
Android firstly checks API version against the function call receiver type, so we should do the same to be consistent.
(cherry picked from commit c3d01ec)
(cherry picked from commit 5c78acc)
Manually mute the class literal test in apiCheck.kt; support for new class
literal expressions is postponed because it's not straightforward to combine
both unbound (Type::class) and bound (instance::class) class literals in one
UClassLiteralExpression: in Java they're two very different expressions
(Type.class and instance.getClass())
Nicolay Mitropolsky