When making KtLightNullabilityAnnotation after test org.jetbrains.kotlin.idea.caches.resolve.IdeLightClassTestGenerated.NullabilityAnnotations#testJvmOverloads
started failing the wrong assumption was made that for
@JvmOverloads-generated overloads their last parameter is always nullable
(see removed isNullableInJvmOverloads function) and that lead to a bug,
namely KT-28556.
The actual problem of this test started failing was incorrect definition
of kotlinOrigin in KtLightParameter for case of JvmOverloads:
wrong KtParameter was being chosen before
This commit fixes the issue by propagating how actually generated
parameters in codegen relate to source KtParameters'
^KT-28556 Fixed
It's gonna be used in the later commits
Also simplify a bit related code in `_type` initializer:
it seems safe just to map `kotlinType` as is for all non-trivial cases,
also note that all of them are actually generated without generic signature
There's no need to add "values"/"valueOf" methods for them
(see com.intellij.psi.impl.compiled.StubBuildingVisitor#visitMethod that ignores them too)
We already have tests that check enum entries/synthetic methods
are properly resolved in Java:
idea/testData/kotlinAndJavaChecker/javaAgainstKotlin/*Enum*
This commit fixes the exception attached to the bottom of the message
The problem is that when creating ChangeSignatureProcessor for old PsiMethod
that points to the parameter that is already removed from PSI, some pieces
of platform code run resolution on the light PSI that eventually checks
if the source element is valid.
For KtUltraLightParameter, it inherits "isValid" from LightElement and
the latter is defined as getNavigationElement().isValid(),
while here navigationElement points to already removed parameter,
and marked as invalid.
The simplest solution was to define KtUltraLightParameter::isValid
as it was before ultra-light classes, i.e. checking if parent is valid
(see KtLightElementBase::isValid)
com.intellij.psi.PsiInvalidElementAccessException: Element: class com.intellij.psi.impl.compiled.ClsJavaCodeReferenceElementImpl #JAVA because: File language:Language: JAVA != Provider base language:Language: kotlin
invalidated at: no info
at com.intellij.psi.util.PsiUtilCore.ensureValid(PsiUtilCore.java:482)
at com.intellij.psi.impl.source.PsiClassReferenceType.resolveGenerics(PsiClassReferenceType.java:190)
at com.intellij.psi.impl.source.PsiClassReferenceType.resolve(PsiClassReferenceType.java:138)
at com.intellij.psi.util.PsiUtil.resolveClassInType(PsiUtil.java:445)
at com.intellij.psi.util.PsiUtil.convertAnonymousToBaseType(PsiUtil.java:484)
at com.intellij.psi.impl.light.LightTypeElement.<init>(LightTypeElement.java:33)
at com.intellij.psi.impl.PsiElementFactoryImpl.createTypeElement(PsiElementFactoryImpl.java:142)
at com.intellij.refactoring.changeSignature.JavaChangeInfoImpl.fillOldParams(JavaChangeInfoImpl.java:218)
at com.intellij.refactoring.changeSignature.JavaChangeInfoImpl.<init>(JavaChangeInfoImpl.java:127)
at com.intellij.refactoring.changeSignature.JavaChangeInfoImpl.<init>(JavaChangeInfoImpl.java:86)
at com.intellij.refactoring.changeSignature.ChangeSignatureProcessor.generateChangeInfo(ChangeSignatureProcessor.java:121)
at com.intellij.refactoring.changeSignature.ChangeSignatureProcessor.<init>(ChangeSignatureProcessor.java:88)
at org.jetbrains.kotlin.idea.refactoring.changeSignature.KotlinChangeInfo$getOrCreateJavaChangeInfos$3.invoke(KotlinChangeInfo.kt:400)
at org.jetbrains.kotlin.idea.refactoring.changeSignature.KotlinChangeInfo$getOrCreateJavaChangeInfos$5.invoke(KotlinChangeInfo.kt:469)
at org.jetbrains.kotlin.idea.refactoring.changeSignature.KotlinChangeInfo.getOrCreateJavaChangeInfos(KotlinChangeInfo.kt:498)
at org.jetbrains.kotlin.idea.refactoring.changeSignature.KotlinChangeSignatureUsageProcessor.processUsage(KotlinChangeSignatureUsageProcessor.kt:847)
at com.intellij.refactoring.changeSignature.ChangeSignatureProcessorBase.doChangeSignature(ChangeSignatureProcessorBase.java:218)
- Extract HOF that UltraLightSupport::mapType that allows to call
arbitrary functions of type mapper
- Use it for computing return type of functions
- "declaration: KtDeclaration" parameter became unused since it was only
used for return types
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
to fix generics in
class A<E> {
fun foo(): E = null!!
}
public class B {
public static void main(String[] args) {
A<String> a = new A<>();
a.foo().length(); // Unresolved length, because it thinks that `a.foo()` returns E
}
}
Map Kotlin built-in classes (e.g. Throwable) to corresponding Java
classes, do not map Unit to void, support arrays of primitives and
arrays of wrapper types
Add PropertyDescriptor.backingField/delegateField to store annotations
on the field directly in an otherwise almost empty descriptor instance,
instead of storing them with use-sites in the corresponding property
descriptor. Instead of AnnotationWithTarget, create AnnotationDescriptor
instances in AnnotationSplitter. Change DescriptorRenderer to render
annotations on "related" declarations when needed, with the explicit
use-site target if applicable.
Most changes in diagnostic test data are related to the fact that
annotations which are known to have an incompatible use-site to the
declaration they're applied at (such as `@param:`-annotation on a
function), are now not loaded at all. It's fine because the code is
erroneous, so it doesn't really matter how do we load annotations with
invalid targets (some of this logic is also changed freely in subsequent
commits). Some changes are also explained by the fact that for example
an annotation on the property which is only applicable to FIELD is now
rendered with an explicit use-site target `@field:`, regardless of
whether it did have that use-site target syntactically or not.
Basically, after this change there's no point in calling
Annotations.getUseSiteTargetedAnnotations/getAllAnnotations anymore
because it's easier and more intuitive to just use Annotations of the
corresponding descriptor -- the backing / delegate field (introduced in
this commit) or the extension receiver / setter parameter (related
behavior was fixed in previous commits). Usages of
use-site-target-related methods will be refactored out in subsequent
commits
Denis Zharkov