When trying to estimate if annotation entry might be resolved
to a specified fqName we should track the short name from entry itself
instead of the short name of desired annotation
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)
The main implementation in DefaultCallGenerator did not use anything
from that parameter anyway in 99% cases, except the type, which is
passed separately now as JvmKotlinType. This will be useful to implement
call generation for functions which do not have descriptors for their
value parameters (such as signature-polymorphic)
#KT-14416 In Progress
- Add the tests mute system for the diagnostic tests
- Move the code for the test info parsing to the separate package `parsers`
- Unification of the `linked` and `not linked` spec tests
- Package structure is refactored
- Change the multiline comment format with a test information
- Actualize `PrintSpecTestsStatistic`
- Other different code improvements
{ T : Any? & Foo & Bar? }!! -> { T!! & Foo & Bar }
Also, fix bug with loosing non-representative number type.
For example, for type { Byte & SomeType } we lost type `Byte` because
`getDefaultPrimitiveNumberType` returns null for it
Fixes #KT-28334 for NI
In previous commits, renderValueParameter began to calculate its
containing declaration. However, WrappedValueParameterDescriptor
assumes that parent of IrParameter is IrFunction, which is not true
for dispatch receiver parameters. The correct fix would be not to create
WrappedValueParameterDescriptor for dispatch receivers at all and use
WrappedReceiverParameterDescriptor instead. In this fix, I just moved
parameter' containing declaration calculation inside specific option
which is usually false, thus hiding the found problem.
#KT-27868 Fixed
Previously given dirtyFiles was removed from complementaryFilesMap
exactly on call of clearComplementaryFilesMapping. This causes fail
of next build in case of compilation error of previous build on JPS
(since complementary files not known on second build). The right way
to do it is removing (replacing) them only after successful
build.
This was working on Gradle since Gradle rebuilds whole module (project)
in case of build error.
Denis Zharkov