Create ExternalSignatureResolver which can resolve propagated and alternative
signatures, use it in JavaFunctionResolver and JavaConstructorResolver.
Move JavaValueParameterResolver.ValueParameters to SignaturesPropagationData,
since elsewhere it always had receiverType = null
Aside from refactorings, minor changes in logic are made:
- to find out if a type of a value parameter is vararg ('ellipsis type'), we
now check if the method is vararg and the parameter is its last parameter
(instead of 'instanceof PsiEllipsisType')
- 'visitedSuperclasses' is now a Set: this better reflects what it's supposed
to represent. Also result check of the 'add()' method on a List was useless
Now it has the only method returning Initializer, an object which can be told
to initialize resolved descriptors later, or to obtain these descriptors.
Delete useless methods, combine the remaining ones
- create JavaTypeSubstitutor as a mirror for PsiSubstitutor
- copy-paste MethodSignatureUtil.areSignaturesErasureEqual() and migrate it to
JavaTypeSubstitutor
- use a pair of method and substitutor instead of
'MethodSignatureBackedByPsiMethod'
- add JavaClass.getDefaultType() which goes into JavaPsiFacade and creates an
unsubstituted PsiClassType for the class
- green code
The only PSI usage left is TypeConversionUtil.erasure(), which needs to be
copied and migrated somehow
- move JetClsMethod and JetJavaMirrorMarker to 'jetAsJava' package
- move JetClsMethodImpl out of 'wrappers' packages
- move TypeVariableResolver to 'resolver' package, make it package-local
- move MembersCache and NamedMembers to 'scope', make the former package-local
Add more wrapper methods to JavaClassifierType.
Inline the utility method adjustTypeUsageWithMutabilityAnnotations to the two
places where it was used. Also add JavaAnnotationOwner and change signature of
JavaAnnotationResolver to take JavaAnnotationOwner, not PSI
JavaClassifier is a common type for JavaClass and JavaTypeParameter. In almost
all of the places JavaClass remains to be JavaClass, except for the resolution
result of JavaClassType, which can be a type parameter. Add an assertion that
JavaClass is created only for a class and not for a type parameter. Delete
different creations of JavaClass in 'idea' (where there can be a type
parameter) by changing the interface of util functions.
Delete JavaModifierListOwnerImpl, extract its methods into JavaElementUtil and
use these implementations for every JavaModifierListOwner
Continue refactoring JavaTypeTransformer to work with JavaType, not PsiType
Use an instanceof-chain on a JavaType instance instead of PsiTypeVisitor in
TypeTransformer. Add a special method to handle vararg types, use it in
ValueParameterResolver
Use JavaType instead of PsiType whenever possible.
In this commit the logic of checking whether a loaded parameter is a vararg
changed: instead of checking if the corresponding PsiType is PsiEllipsisType we
now check if the containing method has the ACC_VARARG modifier
Several places are still left and need special handling. The overall behavior
of the resolver should not change in this commit (except for maybe different
small operations like creating names, fq-names, ...)
There were two usages of RuntimeHandleClassesMode.REPORT_ERROR: first in tests,
where it never occurred, second in JavaClassResolver, where it's now inlined
HACK: determine whether fqname is a name for class contained in class or namespace based on virtual file name
This commit introduces code duplication which is hard to avoid without major refactoring
Alexander Udalov