Commit Graph

516 Commits

Author SHA1 Message Date
Alexander Udalov 3f1533c35b Restore support for local class literals in annotation arguments
This was broken in c1ab08c8ce where we started to represent KClassValue
as a ClassId of the referenced class + number of times it's been wrapped
into kotlin.Array. Local classes do not have a sane ClassId, so in this
change we restore the old behavior by representing KClassValue with a
sealed class value instead

 #KT-29891 Fixed
2019-02-25 19:22:09 +01:00
Yan Zhulanow 0657a3d399 New evaluator that doesn't depend on the 'extract function' refactoring (KT-28192, KT-25220, KT-25222, KT-21650) 2019-02-25 14:43:57 +03:00
Nicolay Mitropolsky 76bdfddfea Making KotlinAnnotatedElementsSearcher able to search for parameters (KT-27794) 2019-02-18 14:08:09 +03:00
Denis Zharkov 1a630773cf Fix parent and containingFile for throws-reference list
Otherwise, exception is thrown during type inference
because default implementations effectively return null

^KT-29287 Fixed
2019-02-06 16:26:28 +03:00
Mikhael Bogdanov a122cba862 Switch Kotlin project to jvm-target 1.8
#KT-29405
2019-01-31 07:43:05 +01:00
Sergey Rostov 0f2fb4ff82 Build: remove intellijCore/annotations.jar usages 2019-01-28 13:43:08 +03:00
Vyacheslav Gerasimov 818910267e Remove 173 bunch files 2019-01-14 21:29:02 +03:00
Nicolay Mitropolsky ebd6caaa71 Light-annotations: fix for reading class-literal varargs (KT-29027, IDEA-204252) 2018-12-27 16:04:05 +03:00
Mikhail Glukhikh 661ac711c0 Fix light class generation for local classes in scripts
Before this commit, we used script context for all classes
defined in script. However, for local classes in scripts it's mistake,
and now we generate them as usual, despite of the fact we are in script.

#KT-28997 Fixed
2018-12-26 12:53:24 +03:00
Denis Zharkov 5052623c0b Minor. Add a comment to KtLightElement::givenAnnotations 2018-12-18 09:31:13 +03:00
Denis Zharkov e0975df1c0 Create annotation arguments in ultra-light classes via PsiElementFactory 2018-12-18 09:31:13 +03:00
Denis Zharkov 5c083d798e Restrict search scope for KtUltraLightParameter
^KT-28365 Fixed
2018-12-18 09:31:13 +03:00
Denis Zharkov 859223baa2 Fix throws-list for case of kotlin.Throwable in ultra-light classes 2018-12-18 09:31:13 +03:00
Denis Zharkov b16bfad079 Do not generate no-arg constructor for sealed ultra-light class 2018-12-18 09:31:13 +03:00
Denis Zharkov 2f8b214e76 Support annotation based on descriptor in ultra-light classes
It helps to generate properly the annotations for delegates
Also note in test, that annotations in Base class have really weird
text of arguments and also don't have names
2018-12-18 09:31:13 +03:00
Denis Zharkov 63907b1a6b Minor. Introduce typeMapper val into UltraLightSupport
To avoid multiple creation
2018-12-18 09:31:13 +03:00
Denis Zharkov 52d5143dd7 Support delegating to interfaces in ultra-light classes 2018-12-05 16:34:44 +03:00
Denis Zharkov dbf9ff29a9 Support data classes in ultra-light classes 2018-12-05 16:34:44 +03:00
Denis Zharkov 8b65311769 Minor. Extract KtUltraLightMethodForSourceDeclaration 2018-12-05 16:34:44 +03:00
Denis Zharkov b73760c3fc Get rid of redundant method KtUltraLightParameter::annotatedOrigin 2018-12-05 16:34:44 +03:00
Denis Zharkov bbaa4c225d Introduce subclasses for KtUltraLightParameter
Mostly, it's needed for clarity and to simplify
what exactly `kotlinOrigin` means in each case:
- Note, that annotatedOrigin() is always kotlinOrigin
- We don't need to store another field for receiver
- Now, kotlinOrigin is consistent with KtLightParameter::kotlinOrigin
2018-12-05 16:34:44 +03:00
Denis Zharkov ad2f02b12e Minor. Get rid of redundant is check and unused method
Now, nullability for ultra-light elements is processed via KtUltraLightNullabilityAnnotation
2018-12-05 16:34:44 +03:00
Denis Zharkov 28d3a62567 Separate nullability annotation processing for ultra-light classes
KtLightNullabilityAnnotation is specifically designed for old light classes
and includes a bunch of hacks that are applicable for them

So, we have to introduce own hack into it
(see org.jetbrains.kotlin.asJava.classes.KtUltraLightParameter#getTypeForNullability)
that is a bit of hard to support when extending hierarchy
2018-12-05 16:34:44 +03:00
Denis Zharkov d7d0407afb Fix parameters nullability for generated overloads in light classes
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
2018-12-05 16:34:44 +03:00
Denis Zharkov ac19cc9376 Extract kotlinType property in KtUltraLightField
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
2018-12-05 16:34:44 +03:00
Denis Zharkov efc39c6137 Minor. Reformat KtLightModifierList.kt and make function private 2018-12-05 16:34:44 +03:00
Nikolay Krasko 0aec18c440 Minor: explain in comment when light class can be null 2018-11-29 13:31:08 +03:00
Denis Zharkov 23c43cd124 Support retrieving class of enum entry in ultra-light classes 2018-11-26 11:36:43 +03:00
Denis Zharkov 5cf2d659dc Minor. Split ultraLightPsi.kt into three files
By one for PsiClass, PsiField and PsiMethod implementations
2018-11-26 11:36:31 +03:00
Denis Zharkov aa5a2a2643 Support @JvmField on primary ctr properties in ultra-light classes 2018-11-26 11:36:29 +03:00
Denis Zharkov 206466f6ce Support enums in ultra-light classes
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*
2018-11-26 11:36:28 +03:00
Denis Zharkov ca9f42f449 Support @JvmName in ultra-light classes 2018-11-26 11:36:27 +03:00
Denis Zharkov 17328a442a Support @JvmSynthetic in ultra-light classes 2018-11-26 11:36:26 +03:00
Denis Zharkov 91c86f7f56 Fix refactorings that remove parameter based on ultra-light classes
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)
2018-11-26 11:36:25 +03:00
Denis Zharkov 7de8b4de4e Support declarations returning object literals in ultra-light classes 2018-11-26 11:36:25 +03:00
Denis Zharkov 28f20a97f8 Support @JvmOverloads annotation in ultra-light classes 2018-11-26 11:25:42 +03:00
Denis Zharkov 41997769e3 Support @JvmField annotation in light classes 2018-11-26 11:25:42 +03:00
Dmitry Petrov b3ce2eea39 Add LanguageVersionSettings to KotlinTypeMapper
KotlinTypeMapper clients should use proper LanguageVersionSettings when
possible.
2018-11-21 12:01:41 +03:00
Denis Zharkov 580d03be5f Support JvmWildcard/JvmSuppressWildcard in ultra-light classes
The idea is reusing logic from KotlinTypeMapper for that
2018-11-19 14:40:51 +03:00
Denis Zharkov ce3b489fa9 Avoid using CheckSignatureAdapter in ultra-light classes 2018-11-19 14:40:51 +03:00
Denis Zharkov 037ad2923c Minor. Rename parameter in KtUltraLightClass::asJavaMethod 2018-11-19 14:40:51 +03:00
Denis Zharkov e15e82e1a9 Refactor KotlinType::asPsiType for ultra-light classes
- 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
2018-11-19 14:40:51 +03:00
Denis Zharkov d74c12323f Fix ambiguity when KtUltraLightClass contains overrides
#KT-27987 Fixed
2018-11-08 15:25:41 +03:00
Denis Zharkov 234776820b Use KotlinLightReferenceListBuilder for type parameters bounds
It doesn't run resolve() on freshly added reference, thus the latter is
not failing in recursive case like T : Enum<T>
2018-11-08 15:25:41 +03:00
Denis Zharkov a4cc67d0a0 Refine isInlineOnly check in KtUltraLightClass 2018-11-08 15:25:41 +03:00
Denis Zharkov 34f9a1e70e Do not build no-arg constructor overload for inner KtUltraLightClass 2018-11-08 15:25:41 +03:00
Denis Zharkov 8999a21764 Refine visibility computation for lateinit's field in KtUltraLightClass 2018-11-08 15:25:41 +03:00
Denis Zharkov 6fc8c98aea Avoid calling PsiType::resolve while adding supertype references
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
2018-11-08 15:25:41 +03:00
Denis Zharkov 34e8ce6a48 Fix data race in LightReferenceListBuilder
Effectively this is a cherry-pick of
https://github.com/JetBrains/intellij-community/commit/75032008695977f171540b5f0e055b77aa682c0c
2018-11-08 15:25:41 +03:00
Denis Zharkov 94d9fd8b72 Add our own version of LightReferenceListBuilder
There are some issues with one from the platform that may be backported
at some moment, but now it's faster to have our own implementation
2018-11-08 15:25:41 +03:00