Before this commit, we compared property visibility with constructor
visibility only, which is incorrect. Now we compare property visibility
also with class visibility
#KT-19613 Fixed
Otherwise, e.g. in case of inner classes it may lead to
StackOverflowError:
- Someone tries to resolve supertypes
- We're starting building extends/implements lists
- Then calling resolve on the type references leads that some logic
in Java resolution again is trying to resolve supertype of the same
class (only in case of inner ones)
Probably, it could be fixed on the side of Java resolve
but at the same time it's clear that calling `resolve` while building
extends list it's really somewhat not very cool
The exception is following:
at org.jetbrains.kotlin.asJava.classes.KtLightClassForSourceDeclaration$_extendsList$2.invoke(KtLightClassForSourceDeclaration.kt:77)
at org.jetbrains.kotlin.asJava.classes.KtLightClassForSourceDeclaration$_extendsList$2.invoke(KtLightClassForSourceDeclaration.kt:73)
at kotlin.SafePublicationLazyImpl.getValue(LazyJVM.kt:107)
at org.jetbrains.kotlin.asJava.classes.KtLightClassForSourceDeclaration.get_extendsList(KtLightClassForSourceDeclaration.kt)
at org.jetbrains.kotlin.asJava.classes.KtLightClassForSourceDeclaration.getExtendsList(KtLightClassForSourceDeclaration.kt:320)
at com.intellij.psi.impl.PsiClassImplUtil.getExtendsListTypes(PsiClassImplUtil.java:1017)
at com.intellij.psi.impl.light.AbstractLightClass.getExtendsListTypes(AbstractLightClass.java:137)
at com.intellij.psi.impl.ScopedClassHierarchy.getSuperTypes(ScopedClassHierarchy.java:95)
at com.intellij.psi.impl.ScopedClassHierarchy.visitType(ScopedClassHierarchy.java:80)
at com.intellij.psi.impl.ScopedClassHierarchy.getSuperClassSubstitutor(ScopedClassHierarchy.java:115)
at com.intellij.psi.impl.JavaClassSupersImpl.getSuperSubstitutorWithCaching(JavaClassSupersImpl.java:111)
at com.intellij.psi.impl.JavaClassSupersImpl.getSuperClassSubstitutor(JavaClassSupersImpl.java:71)
at com.intellij.psi.util.TypeConversionUtil.getMaybeSuperClassSubstitutor(TypeConversionUtil.java:1089)
at com.intellij.psi.util.TypeConversionUtil.getClassSubstitutor(TypeConversionUtil.java:1055)
at com.intellij.psi.impl.compiled.ClsJavaCodeReferenceElementImpl.advancedResolveImpl(ClsJavaCodeReferenceElementImpl.java:143)
at com.intellij.psi.impl.compiled.ClsJavaCodeReferenceElementImpl.access$000(ClsJavaCodeReferenceElementImpl.java:43)
at com.intellij.psi.impl.compiled.ClsJavaCodeReferenceElementImpl$Resolver.resolve(ClsJavaCodeReferenceElementImpl.java:121)
at com.intellij.psi.impl.compiled.ClsJavaCodeReferenceElementImpl$Resolver.resolve(ClsJavaCodeReferenceElementImpl.java:115)
at com.intellij.psi.impl.source.resolve.ResolveCache.lambda$resolveWithCaching$1(ResolveCache.java:203)
at com.intellij.openapi.util.RecursionManager$2.doPreventingRecursion(RecursionManager.java:99)
at com.intellij.psi.impl.source.resolve.ResolveCache.resolveWithCaching(ResolveCache.java:202)
at com.intellij.psi.impl.compiled.ClsJavaCodeReferenceElementImpl.multiResolve(ClsJavaCodeReferenceElementImpl.java:223)
at com.intellij.psi.impl.compiled.ClsJavaCodeReferenceElementImpl.advancedResolve(ClsJavaCodeReferenceElementImpl.java:213)
at com.intellij.psi.impl.source.PsiClassReferenceType.resolveGenerics(PsiClassReferenceType.java:191)
at com.intellij.psi.impl.source.PsiClassReferenceType.resolve(PsiClassReferenceType.java:138)
at org.jetbrains.kotlin.asJava.classes.LightReferenceListBuilder.addReference(LightReferenceListBuilder.java:53)
at org.jetbrains.kotlin.asJava.classes.KtUltraLightClass.createExtendsList(ultraLightPsi.kt:91)
at org.jetbrains.kotlin.asJava.classes.KtLightClassForSourceDeclaration$_extendsList$2.invoke(KtLightClassForSourceDeclaration.kt:77)
at org.jetbrains.kotlin.asJava.classes.KtLightClassForSourceDeclaration$_extendsList$2.invoke(KtLightClassForSourceDeclaration.kt:73)
at kotlin.SafePublicationLazyImpl.getValue(LazyJVM.kt:107)
at org.jetbrains.kotlin.asJava.classes.KtLightClassForSourceDeclaration.get_extendsList(KtLightClassForSourceDeclaration.kt)
at org.jetbrains.kotlin.asJava.classes.KtLightClassForSourceDeclaration.getExtendsList(KtLightClassForSourceDeclaration.kt:320)
at com.intellij.psi.impl.PsiClassImplUtil.getExtendsListTypes(PsiClassImplUtil.java:1017)
at com.intellij.psi.impl.light.AbstractLightClass.getExtendsListTypes(AbstractLightClass.java:137)
a
This commit restores the heuristic removed in 9df02b2366, but only
enables it in case the class wasn't found with the name mapped initially
according to the InnerClasses attribute values. This helps to support
class files which do not have the InnerClasses attribute for all nested
referenced classes, such as those generated by Groovy.
Note that in theory it's still possible for this code to behave
incorrectly, for example a reference to a class `C` nested in a
_top-level_ class named `A$B` will not be loaded by this code correctly.
This is a lower-priority issue and it will need to be fixed later.
#KT-27874 Fixed
The only place where a name with dots was passed to
ClassifierResolutionContext.mapInternalNameToClassId was in
BinaryClassSignatureParser.parseParameterizedClassRefSignature, where
for some reason names can be both of internal (`a/b$c`) and canonical
(`a/b.c`) form. Supporting both names in mapInternalNameToClassId was
confusing because JVM internal names cannot contain dots. Replace dots
with dollars in parseParameterizedClassRefSignature to get rid of the
dot-name handling in mapInternalNameToClassId and rely on the correct
(simplified) InnerClasses-based name resolution later instead.
Also inline mapDescToClassId to its only usage.
Mikhail Glukhikh