Broken behaviour when using unimplemented inheritance

[elken]

So using a dummy maven application generated from https://start.spring.io/ and the below files added:

IThing.kt

interface IThing {
    fun behaviour
}

Thing.kt

class Thing : IThing

trying to invoke a code action in emacs throws the exception below:

async2    Internal error: org.javacs.kt.util.KotlinLSException: Error while analyzing: class Thing : IThing
java.util.concurrent.CompletionException: org.javacs.kt.util.KotlinLSException: Error while analyzing: class Thing : IThing
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1702)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.javacs.kt.util.KotlinLSException: Error while analyzing: class Thing : IThing
	at org.javacs.kt.compiler.Compiler.compileKtExpression(Compiler.kt:544)
	at org.javacs.kt.CompiledFile.bindingContextOf(CompiledFile.kt:45)
	at org.javacs.kt.CompiledFile.referenceAtPoint(CompiledFile.kt:68)
	at org.javacs.kt.hover.HoversKt.hoverAt(Hovers.kt:25)
	at org.javacs.kt.KotlinTextDocumentService$hover$1.invoke(KotlinTextDocumentService.kt:102)
	at org.javacs.kt.KotlinTextDocumentService$hover$1.invoke(KotlinTextDocumentService.kt:97)
	at org.javacs.kt.util.AsyncExecutor.compute$lambda-2(AsyncExecutor.kt:19)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
	... 3 more
Caused by: org.jetbrains.kotlin.util.KotlinFrontEndException: Exception while analyzing expression at (1,3) in /dummy.virtual.kt

Attachments:
expression.kt
class Thing : IThing
	at org.jetbrains.kotlin.types.expressions.ExpressionTypingVisitorDispatcher.logOrThrowException(ExpressionTypingVisitorDispatcher.java:253)
	at org.jetbrains.kotlin.types.expressions.ExpressionTypingVisitorDispatcher.lambda$getTypeInfo$0(ExpressionTypingVisitorDispatcher.java:224)
	at org.jetbrains.kotlin.util.PerformanceCounter.time(PerformanceCounter.kt:101)
	at org.jetbrains.kotlin.types.expressions.ExpressionTypingVisitorDispatcher.getTypeInfo(ExpressionTypingVisitorDispatcher.java:164)
	at org.jetbrains.kotlin.types.expressions.ExpressionTypingVisitorDispatcher.getTypeInfo(ExpressionTypingVisitorDispatcher.java:147)
	at org.jetbrains.kotlin.types.expressions.ExpressionTypingServices.getTypeInfo(ExpressionTypingServices.java:120)
	at org.jetbrains.kotlin.types.expressions.ExpressionTypingServices.getTypeInfo(ExpressionTypingServices.java:95)
	at org.javacs.kt.compiler.Compiler.compileKtExpression(Compiler.kt:533)
	... 10 more
Caused by: java.lang.UnsupportedOperationException: Should not be called
	at org.jetbrains.kotlin.resolve.lazy.NoTopLevelDescriptorProvider.shouldNotBeCalled(TopLevelDescriptorProvider.kt:36)
	at org.jetbrains.kotlin.resolve.lazy.NoTopLevelDescriptorProvider.getPackageFragment(TopLevelDescriptorProvider.kt:39)
	at org.jetbrains.kotlin.resolve.DeclarationResolver.getTopLevelDescriptorsByFqName(DeclarationResolver.kt:107)
	at org.jetbrains.kotlin.resolve.DeclarationResolver.checkRedeclarationsInPackages(DeclarationResolver.kt:86)
	at org.jetbrains.kotlin.resolve.LazyTopDownAnalyzer.analyzeDeclarations(LazyTopDownAnalyzer.kt:216)
	at org.jetbrains.kotlin.types.expressions.LocalClassifierAnalyzer.processClassOrObject(LocalClassifierAnalyzer.kt:120)
	at org.jetbrains.kotlin.types.expressions.ExpressionTypingVisitorForStatements.visitClass(ExpressionTypingVisitorForStatements.java:167)
	at org.jetbrains.kotlin.types.expressions.ExpressionTypingVisitorForStatements.visitClass(ExpressionTypingVisitorForStatements.java:68)
	at org.jetbrains.kotlin.psi.KtClass.accept(KtClass.kt:20)
	at org.jetbrains.kotlin.types.expressions.ExpressionTypingVisitorDispatcher.lambda$getTypeInfo$0(ExpressionTypingVisitorDispatcher.java:175)
	... 16 more
..orker-19Excluding symbol com.android.tools.build.bundletool.validation.AutoValue_TextureCompressionFormatParityValidator_SupportedTextureCompressionFormats from index since its name is too long

Java version:

openjdk 11.0.11 2021-04-20 LTS
OpenJDK Runtime Environment Zulu11.48+21-CA (build 11.0.11+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.48+21-CA (build 11.0.11+9-LTS, mixed mode)

Environment:

Emacs 28.1 (built from nix)

[elken]

This seems to apply to basically everything I'm working on now, not just that isolated case :l

[themkat]

The stack trace you are showing happens a lot, yes... It happens because of failing to fetch hover information. Unsure on why it happens. Any variations on the stack traces is very appreciated if they happen and you want to post them 🙂 May get time to look into some issues in this repo this summer (vacation/off work soon), so all information that can help to make fixes are awesome!

Invoking the code action issue, and nothing happening, is another issue. The reason for that one is that the current implementation of implement abstract members expect there to be a body for the class. So it just silently fails. I'm planning on looking into a fix this week unless you want to 🙂

EDIT: One more thing! At least on my local machine with lsp-mode in Emacs, I have to mark the entire class (i.e, class Thing in your case above to run the implement abtract members quick fix. I'm going to look into that at one point as well. That may be the issue you are facing. Feel free to look into it if you want to. A bit boggled up with other issues I'm currently looking at, and I don't think we are that many Emacs users working on stuff in this repo 🙁

[elken]

It doesn't just apply to the original issue, it applies to (in the project I work on) every operation in every file. I tested a few other dummy kotlin projects and unless I have everything perfect (and use gradle) I get no code actions anywhere.

The stack traces that have been thrown are exactly the same, except the code they complain about is different.

On looking at other issues, I'm far from a kotlin expert but I can at least lend my emacs expertise for sure :) A useful starting point to understand what's happening would be appreciated!

[themkat]

The indexing often takes a tiny bit of time to complete as well, especially for the "add missing imports"-quickfix. Did you wait for it to finish? Also, there aren't that many code actions. The only one two that works for me without issue is the add missing import and implement abstract members one.

To fix the issue with the "Implement abstract members" code action not showing up (unless marking the code described above), I would start by looking at the Range-calculations in the quickfix for implement abstract members (the tests might also be a bit of help when it comes to what LSP type requests are sent, and the parameters). Now it checks that the range is exactly a given bound at the moment. To my experience, Emacs does not give the same range, but gives the position of the cursor. VSCode on the other hand gives these ranges like expected. Should the fix be in lsp-mode in Emacs? I'm unsure, but based upon my experience of implementing "add missing imports", it should be pretty straightforward to make it work like expected in Emacs without changing lsp-mode. Could probably fix it myself, but I would be super happy if you try instead 🙂 More people getting familiar with the codebase and possibly contributing is awesome!

Let me know if you need additional details 🙂 Hope the above makes sense. My brain is tired after work and the heat here 😛

[elken]

Did you wait for it to finish?

No idea how long that is meant to take, but yeah this has been a project left in emacs for days 😛

Also, there aren't that many code actions

I know there are at least a few, but no matter what I do (outside of the "perfect" project), even though the server complains about things, everything always says "no actions available"

As for the rest, I'll try and find time to look into it :D

[themkat]

@elken , did you find time to look into it? 🙂 If not, I will probably take a look at it very soon. Gotten way too tired of having to do the workaround I described above for the "Implement abstract members" code action to show up 😛

[elken]

Have been super busy and don't use kotlin anymore now 😅

I can be around to help test stuff!