This is actually either a LAMBDA or an ANONYMOUS_FUNCTION.
Not quite sure if it's really required, but some tools such as IR-based
decompiler might require this information.
The might be code that stores light class references (for example
ChangeMethodSignatureFromUsageFix) and tries to find methods
after invalidating. Internal class caches has an additional assert that
methods obtained are valid and this assert can be violated if the list
of methods was cached before some method invalidation.
This a major problem of current light-classes implementation. Other
places should be checked and fixed as well.
Check test:
QuickFixMultiFileTestGenerated$ChangeSignature$Jk.testJkKeepValOnAddingParameter1
Caused by: java.lang.AssertionError: Element: class org.jetbrains.kotlin.asJava.classes.KtUltraLightMethodForSourceDeclaration #kotlin because: File language:Language: JAVA != Provider base language:Language: kotlin
invalidated at: no info
Attachments:
at com.intellij.testFramework.LoggedErrorProcessor.processError(LoggedErrorProcessor.java:61)
at org.jetbrains.kotlin.idea.test.KotlinLightCodeInsightFixtureTestCase$setUp$1.processError(KotlinLightCodeInsightFixtureTestCase.kt:84)
at com.intellij.testFramework.TestLogger.error(TestLogger.java:40)
at com.intellij.openapi.diagnostic.Logger.error(Logger.java:170)
at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.lambda$null$1(PassExecutorService.java:442)
at com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:1166)
at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.lambda$doRun$2(PassExecutorService.java:423)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:586)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:532)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:86)
at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.doRun(PassExecutorService.java:422)
at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.lambda$run$0(PassExecutorService.java:398)
at com.intellij.openapi.application.impl.ReadMostlyRWLock.executeByImpatientReader(ReadMostlyRWLock.java:164)
at com.intellij.openapi.application.impl.ApplicationImpl.executeByImpatientReader(ApplicationImpl.java:218)
at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.run(PassExecutorService.java:396)
at com.intellij.concurrency.JobLauncherImpl$VoidForkJoinTask$1.exec(JobLauncherImpl.java:174)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Caused by: com.intellij.psi.PsiInvalidElementAccessException: Element: class org.jetbrains.kotlin.asJava.classes.KtUltraLightMethodForSourceDeclaration #kotlin 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.PsiClassImplUtil$1.add(PsiClassImplUtil.java:380)
at com.intellij.psi.scope.processor.FilterScopeProcessor.execute(FilterScopeProcessor.java:59)
at com.intellij.psi.impl.PsiClassImplUtil.processDeclarationsInClassNotCached(PsiClassImplUtil.java:684)
at com.intellij.psi.impl.PsiClassImplUtil.lambda$createMembersMap$2(PsiClassImplUtil.java:395)
at com.intellij.util.containers.ConcurrentFactoryMap$2.create(ConcurrentFactoryMap.java:181)
at com.intellij.util.containers.ConcurrentFactoryMap.get(ConcurrentFactoryMap.java:45)
at com.intellij.psi.impl.PsiClassImplUtil$MembersMap.get(PsiClassImplUtil.java:357)
at com.intellij.psi.impl.PsiClassImplUtil$MembersMap.access$000(PsiClassImplUtil.java:349)
at com.intellij.psi.impl.PsiClassImplUtil.getMap(PsiClassImplUtil.java:207)
at com.intellij.psi.impl.PsiClassImplUtil.findByMap(PsiClassImplUtil.java:153)
at com.intellij.psi.impl.PsiClassImplUtil.findMethodsByName(PsiClassImplUtil.java:96)
at com.intellij.psi.impl.source.ClassInnerStuffCache.findMethodsByName(ClassInnerStuffCache.java:67)
at org.jetbrains.kotlin.asJava.classes.KtLightClassBase.findMethodsByName(KtLightClassBase.kt:52)
at com.intellij.codeInsight.daemon.impl.quickfix.ChangeMethodSignatureFromUsageFix.getShortText(ChangeMethodSignatureFromUsageFix.java:94)
at com.intellij.codeInsight.daemon.impl.quickfix.ChangeMethodSignatureFromUsageFix.isAvailable(ChangeMethodSignatureFromUsageFix.java:152)
at com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.availableFor(ShowIntentionActionsHandler.java:127)
at com.intellij.codeInsight.intention.impl.CachedIntentions.wrapActionsTo(CachedIntentions.java:183)
at com.intellij.codeInsight.intention.impl.CachedIntentions.wrapAndUpdateActions(CachedIntentions.java:135)
at com.intellij.codeInsight.daemon.impl.ShowIntentionsPass.doCollectInformation(ShowIntentionsPass.java:222)
at com.intellij.codeHighlighting.TextEditorHighlightingPass.collectInformation(TextEditorHighlightingPass.java:69)
at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.lambda$null$1(PassExecutorService.java:430)
... 15 more
There're exceptions from `isWritable` method in light classes caused by
accessing invalid elements.
Override KtLightMemberImpl implementation to avoid activating
decompiler during validity check.
Stack Trace
at kotlin.collections.CollectionsKt___CollectionsKt.first(_Collections.kt:184)
at com.intellij.configurationStore.XmlSerializer.<clinit>(xmlSerializer.kt:15)
at com.intellij.codeInsight.CodeInsightSettings.writeExternal(CodeInsightSettings.java:228)
at com.intellij.testFramework.UsefulTestCase.<clinit>(UsefulTestCase.java:104)
at com.intellij.testFramework.TestLoggerFactory.log(TestLoggerFactory.java:154)
at com.intellij.testFramework.TestLogger.info(TestLogger.java:70)
at org.jetbrains.kotlin.scripting.compiler.plugin.definitions.CliScriptDependenciesProvider.calculateRefinedConfiguration(CliScriptDependenciesProvider.kt:45)
...
Since we now generate file classes even for IR loaded from dependencies
(see 3a9b94235f) to simplify code in certain lowerings, it makes sense
to do that for all source files together before any meaningful
lowerings. The easiest way to do so is to make FileClassLowering a
module-wide phase.
ExpectDeclarationsRemoveLowering is now also a module-wide phase because
it needs to be run before FileClassLowering (to avoid producing empty
facades for files that only contain `expect` declarations)
Similarly to how it's done for callable references. This is needed for
IrTypeMapper to be able to correctly compute the name of the SAM wrapper
IrClass without resorting to the name of the underlying descriptor
(computed in CodegenAnnotatingVisitor)
This is useful to store data that must be kept when the element is
transformed, such as names of local/anonymous classes and
EnclosingMethod values on JVM which are computed before any lowerings.
For now, this is implemented very conservatively: the only field
`attributeOwnerId` which can be used in BackendContext implementation as
a key in the map
Dmitry Petrov