LSP4IJ 0.8.0 Release

[angelozerr]

Hi,

we are about to release LSP4IJ 0.8.0. Highlights of this release include

• improve performance when IJ startup while scanning files indexining is done. In this case, language server don't start and any ay LSP features (codelens, inlay hints, etc) are disabled. When scanning files indexing is finished for all opened projects , language servers starts and all opened editors are refreshed.
• LSP callHierachy and typeHierarchy support.
• fixing several bugs

More details in the changelog.

Please give a try to the latest nightly build.

Unless you report a blocking issue, we'll proceed with the release next Monday 11/25/2024.

cc @CppCXY @InSyncWithFoo @seachicken @KUGDev @AlexWeinstein92 @aparnamichael @MituuZ @turkeylurkey @mrglavas @koxudaxi @FalsePattern @onriv @kristofvb @kdvolder @rcjsuen @jansorg

[CppCXY]

Sudden appearance of double inlay hints while typing, I just updated to the nightly version.

[angelozerr]

That's strange, I have never seen this problem. Which IJ version are you using? Have you the same problem with 0.7.0 with the same IJ version?

[CppCXY]

I am using IDEA 2024.3. This issue occurs occasionally. It happened while I was typing just after updating, but similar issues occurred in previous versions as well. In earlier versions, this issue mainly occurred when switching from a Java project to a Lua project without closing IDEA.

[angelozerr]

Ok if I understand the problem doesn't come from 0.8.0, right? Could you create an issue please.

[CppCXY]

I got a error when I open ide:

com.intellij.openapi.progress.CeProcessCanceledException: com.intellij.openapi.progress.IndicatorCancellationException
	at com.intellij.serviceContainer.ComponentManagerImplKt.runBlockingInitialization$lambda$10(ComponentManagerImpl.kt:1690)
	at com.intellij.openapi.progress.ContextKt.prepareIndicatorThreadContext$lambda$5(context.kt:109)
	at com.intellij.openapi.progress.impl.CoreProgressManager.silenceGlobalIndicator(CoreProgressManager.java:1041)
	at com.intellij.openapi.progress.ContextKt.prepareIndicatorThreadContext(context.kt:107)
	at com.intellij.openapi.progress.ContextKt.prepareThreadContext(context.kt:77)
	at com.intellij.serviceContainer.ComponentManagerImplKt.runBlockingInitialization(ComponentManagerImpl.kt:1675)
	at com.intellij.serviceContainer.ComponentManagerImplKt.doGetOrCreateInstanceBlocking(ComponentManagerImpl.kt:1565)
	at com.intellij.serviceContainer.ComponentManagerImplKt.getOrCreateInstanceBlocking(ComponentManagerImpl.kt:1560)
	at com.intellij.serviceContainer.ComponentManagerImpl.doGetService(ComponentManagerImpl.kt:751)
	at com.intellij.serviceContainer.ComponentManagerImpl.getService(ComponentManagerImpl.kt:695)
	at com.intellij.ide.plugins.PluginUtil.getInstance(PluginUtil.java:14)
	at com.intellij.diagnostic.DefaultIdeaErrorLogger.canHandle(DefaultIdeaErrorLogger.java:39)
	at com.intellij.diagnostic.DialogAppender.queueAppend(DialogAppender.kt:76)
	at com.intellij.diagnostic.DialogAppender.publish(DialogAppender.kt:48)
	at java.logging/java.util.logging.Logger.log(Logger.java:983)
	at org.slf4j.jul.JDK14LoggerAdapter.innerNormalizedLoggingCallHandler(JDK14LoggerAdapter.java:156)
	at org.slf4j.jul.JDK14LoggerAdapter.handleNormalizedLoggingCall(JDK14LoggerAdapter.java:140)
	at org.slf4j.helpers.AbstractLogger.handle_0ArgsCall(AbstractLogger.java:382)
	at org.slf4j.helpers.AbstractLogger.error(AbstractLogger.java:347)
	at com.redhat.devtools.lsp4ij.lifecycle.LanguageServerLifecycleManager.logLSPMessage(LanguageServerLifecycleManager.java:79)
	at com.redhat.devtools.lsp4ij.LanguageServerWrapper.logMessage(LanguageServerWrapper.java:410)
	at com.redhat.devtools.lsp4ij.LanguageServerWrapper.lambda$start$6(LanguageServerWrapper.java:309)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.request(RemoteEndpoint.java:161)
	at org.eclipse.lsp4j.jsonrpc.services.EndpointProxy.invoke(EndpointProxy.java:91)
	at jdk.proxy13/jdk.proxy13.$Proxy174.initialize(Unknown Source)
	at com.redhat.devtools.lsp4ij.LanguageServerWrapper.initServer(LanguageServerWrapper.java:391)
	at com.redhat.devtools.lsp4ij.LanguageServerWrapper.lambda$start$9(LanguageServerWrapper.java:342)
	at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.helpAsyncBlocker(ForkJoinPool.java:1615)
	at java.base/java.util.concurrent.ForkJoinPool.helpAsyncBlocker(ForkJoinPool.java:2686)
	at java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1933)
	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2095)
	at com.redhat.devtools.lsp4ij.internal.CompletableFutures.waitUntilDone(CompletableFutures.java:121)
	at com.redhat.devtools.lsp4ij.features.color.LSPColorProvider.doCollect(LSPColorProvider.java:62)
	at com.redhat.devtools.lsp4ij.features.AbstractLSPInlayHintsProvider$1.collect(AbstractLSPInlayHintsProvider.java:88)
	at com.intellij.codeInsight.hints.CollectorWithSettings.collectHints(InlayHintsUtils.kt:97)
	at com.intellij.codeInsight.hints.InlayHintsPass.doCollectInformation$lambda$1(InlayHintsPass.kt:62)
	at com.intellij.concurrency.ApplierCompleter.processArrayItem(ApplierCompleter.java:126)
	at com.intellij.concurrency.ApplierCompleter.processArray(ApplierCompleter.java:207)
	at com.intellij.concurrency.ApplierCompleter.execAll(ApplierCompleter.java:176)
	at com.intellij.concurrency.ApplierCompleter.lambda$exec$0(ApplierCompleter.java:115)
	at com.intellij.openapi.application.impl.AnyThreadWriteThreadingSupport.tryRunReadAction(AnyThreadWriteThreadingSupport.kt:351)
	at com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:971)
	at com.intellij.concurrency.ApplierCompleter.lambda$wrapInReadActionAndIndicator$2(ApplierCompleter.java:158)
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$14(CoreProgressManager.java:674)
	at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:749)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:705)
	at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:673)
	at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:79)
	at com.intellij.concurrency.ApplierCompleter.wrapInReadActionAndIndicator(ApplierCompleter.java:169)
	at com.intellij.concurrency.ApplierCompleter.wrapAndRun(ApplierCompleter.java:153)
	at com.intellij.concurrency.ApplierCompleter.exec(ApplierCompleter.java:118)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1491)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:2073)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2035)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)
Caused by: com.intellij.openapi.progress.IndicatorCancellationException
	at com.intellij.openapi.progress.ContextKt$cancelWithIndicator$1.invokeSuspend(context.kt:135)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:111)
	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:99)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:608)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:873)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:763)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:750)
Caused by: com.intellij.openapi.progress.ProcessCanceledException
	at com.intellij.openapi.progress.util.AbstractProgressIndicatorBase.throwIfCanceled(AbstractProgressIndicatorBase.java:172)
	at com.intellij.openapi.progress.util.AbstractProgressIndicatorBase.checkCanceled(AbstractProgressIndicatorBase.java:162)
	at com.intellij.codeInsight.daemon.impl.DaemonProgressIndicator.checkCanceled(DaemonProgressIndicator.java:111)
	at com.intellij.openapi.progress.util.ProgressWrapper.checkCanceled(ProgressWrapper.java:84)
	at com.intellij.openapi.progress.ContextKt$cancelWithIndicator$1.invokeSuspend(context.kt:131)
	... 8 more

second error:

java.lang.NullPointerException: Cannot invoke "com.redhat.devtools.lsp4ij.server.StreamConnectionProvider.getInputStream()" because "this.lspStreamProvider" is null
	at com.redhat.devtools.lsp4ij.LanguageServerWrapper.lambda$start$8(LanguageServerWrapper.java:333)
	at java.base/java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:787)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1491)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:2073)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2035)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)

[angelozerr]

If you restart the language server, you should show inlay hints. If you stop the language server inlay hint should disappear, right? Have you again this error?

[CppCXY]

If you restart the language server, you should show inlay hints. If you stop the language server inlay hint should disappear, right? Have you again this error?

yes, It is not always reproducible, but the occurrence probability is very high when I open ide:

[angelozerr]

@CppCXY could you please re-install nigthy and tell me if it is working better (by checking that inlay hint disappear when language server is stopped and re-appear when language server is restarted)?

[CppCXY]

it work well, now!

[angelozerr]

Thanks @CppCXY for your patience!

[mrglavas]

@angelozerr My team spent some time testing the 0.8.0-20241121-092121 nightly build and didn't encounter any new issues. We've put a lot of effort lately into improving the reliability of our automated tests and also have logic to wait until indexing completes before running tests which exercise the language server capabilities through the UI.

[angelozerr]

That's great! Thanks for your feedback.

[angelozerr]

For your information 0.8.0 will provide also CallHierarchy + TypeHiearchy. I will merge sonn #612

Those features are executed withCtrl+Aly+H and Ctrl+H, and it works bydefault only with TEXT and textmate languages. So there is no impact with your ls.

[angelozerr]

I have merged the #612 PR . Please read LSP callHierachy and typeHierarchy support to activate with your language.

[angelozerr]

@InSyncWithFoo please install latest nightly build and declare the callHierachy with your language (see callHierachy and you should enjoy with call hierarchy(hope without bugs).

[onriv]

Hi thanks for the great update and sorry for the too late test! It seems work as expect for my case but for the PR #586 that I am concerning it's not working after index finish. All files are sent the didOpen request without checking isEnabled. I am not sure where it's missed with a first glance though.

[onriv]

I manually tested also the per feature isEnabled, it seems working as expected for me though for the completion feature, my setting for the features are like this and this

[angelozerr]

@InSyncWithFoo could you retry to install nighty build please.

[InSyncWithFoo]

Tried again, still doesn't work. I guess I messed up at some point.

[angelozerr]

Tried again, still doesn't work. I guess I messed up at some point.

Thats super strange. I have no idea about your problem @InSyncWithFoo since with @onriv ls seems working.

[angelozerr]

@InSyncWithFoo I'm really sorry I cannot reproduce your issue. I will create soon the release.

[SCWells72]

I just installed the latest nightly to check out the new features and received the following upon trying out type hierarchy support in TypeScript:

Unhandled exception in [ComponentManager(ProjectImpl@197754269), com.intellij.codeWithMe.ClientIdContextElementPrecursor@2e2935a5, CoroutineName(com.intellij.openapi.wm.impl.ToolWindowManagerImpl), Dispatchers.EDT] java.lang.NullPointerException: Cannot read field "myStructureTreeModel" because "sheet" is null
	at com.intellij.ide.hierarchy.HierarchyBrowserBaseEx.changeView(HierarchyBrowserBaseEx.java:364)
	at com.intellij.ide.hierarchy.HierarchyBrowserBaseEx.changeView(HierarchyBrowserBaseEx.java:341)
	at com.redhat.devtools.lsp4ij.features.typeHierarchy.LSPTypeHierarchyProvider.browserActivated(LSPTypeHierarchyProvider.java:32)
	at com.intellij.ide.hierarchy.actions.BrowseHierarchyActionBase.lambda$createAndAddToPanel$0(BrowseHierarchyActionBase.java:88)
	...

[angelozerr]

I think you have this problem after opening yiur IJ. If you retry it you should not have this error.

It reproduces consistently every time I use Ctrl+H while on the name of a TypeScript class that has been extended in the code base.

Ok I will try it.

But U think typescript language server doent support type Hierarchy. It should support call hierarchy

Should the IDE's type hierarchy action not be disabled for TypeScript, or minimally should it not be defensive against whatever is causing the NPE?

Npe should be fixed. But typescript language server supports only call hierarchy (ctrl+alt+h)

You can see that if you set the lsp console at verbose for typescript. Yiu stop and restart the ls and you should see some server capability like czllHierarchieProvider set to true

Apologies if I'm misunderstanding how LSP works here...

[SCWells72]

But typescript language server supports only call hierarchy (ctrl+alt+h)

Understood. So should the Navigate | Type Hierarchy action be enabled for a TypeScript file? It is:

Perhaps that's not something you can disable selectively proactively and just have to keep it enabled all the time, then react to the request as appropriate for the configured language server?

If the NPE I included above has already been fixed -- presumably not yet in 0.8.0-20241124-150914 as that's the build where I'm seeing it -- and that action ends up being a no-op when unsupported, that's fine. Note that it does end up opening the following tool window along with the error which contains a misleading header about call vs. type hierarchy, though, so it's not a total no-op:

Again, apologies if this isn't a good use of your time. That's not my intention at all. Quite the contrary. As I hope you're inferring from my other activity, I'm very interested in helping with this project -- from which I and users of my own plugin will all benefit -- via both code contribution and end user-type feedback like this. Certainly let me know if you need it filtered a bit, though.

[angelozerr]

I think you have this problem after opening yiur IJ. If you retry it you should not have this error.

It reproduces consistently every time I use Ctrl+H while on the name of a TypeScript class that has been extended in the code base.

But U think typescript language server doent support type Hierarchy. It should support call hierarchy

Should the IDE's type hierarchy action not be disabled for TypeScript, or minimally should it not be defensive against whatever is causing the NPE?

To enable / disable call hierarchy we should start all language servers to collect the server capabilities when they initialize

Starting a language server can slow IJ when it is indexing and can start some times to start (we should wait for this startup to enable / disable this call hierarchy which will freeze IJ)

It is the reason why Calling hierarchy is enabled every time. The check of call huerarchy support is done in the thread which fill the tree of the hierarchy which avoid freezing IJ
Apologies if I'm misunderstanding how LSP works here...

[SCWells72]

I don't know if you've already tried this, but you can have a post-startup action then use DumbService#runWhenSmart() to ensure that it doesn't execute until after initial indexing complete. You can even have it check again and reschedule itself if it happens to kick in between phases of indexing. I just had to do the exact same thing in my plugin a post-startup task that has to be resilient enough to complete successfully on every project open but always after (major) indexing settles.

[angelozerr]

I have indeed tried that but it doesn't work when IntelliJ does "Scanning files..." which is not a dumb but indexing step. It is the reason why I have implemented my own runWhenSmart at https://github.com/redhat-developer/lsp4ij/blob/main/src/main/java/com/redhat/devtools/lsp4ij/client/ProjectIndexingListener.java

[angelozerr]

I just installed the latest nightly to check out the new features and received the following upon trying out type hierarchy support in TypeScript:

Unhandled exception in [ComponentManager(ProjectImpl@197754269), com.intellij.codeWithMe.ClientIdContextElementPrecursor@2e2935a5, CoroutineName(com.intellij.openapi.wm.impl.ToolWindowManagerImpl), Dispatchers.EDT] java.lang.NullPointerException: Cannot read field "myStructureTreeModel" because "sheet" is null
	at com.intellij.ide.hierarchy.HierarchyBrowserBaseEx.changeView(HierarchyBrowserBaseEx.java:364)
	at com.intellij.ide.hierarchy.HierarchyBrowserBaseEx.changeView(HierarchyBrowserBaseEx.java:341)
	at com.redhat.devtools.lsp4ij.features.typeHierarchy.LSPTypeHierarchyProvider.browserActivated(LSPTypeHierarchyProvider.java:32)
	at com.intellij.ide.hierarchy.actions.BrowseHierarchyActionBase.lambda$createAndAddToPanel$0(BrowseHierarchyActionBase.java:88)
	...

Please re install nighthy , it should be fixed.

[SCWells72]

I've confirmed the fix. The type hierarchy view is opened now without error and shows only the current type which is as-expected based on our discussion. Call hierarchly continues to look great. Thanks!

[angelozerr]

I have started the release https://github.com/redhat-developer/lsp4ij/actions/runs/12012988847

After the job is finished we will need to wait for few days the JetBrains approvment.

[mrglavas]

@angelozerr I know it's a bit late but noticed how many PRs were merged after we tested. Does the latest nightly build 0.8.0-20241125-125056 contain everything that's in LSP4IJ 0.8.0?

[angelozerr]

Badly no because I had some feedbacks with some bugs about project indexing that I have fixed.

Type and call hierarchy will not impact you since you have a language different from TEXT and textmate

[angelozerr]

Very bad news, JetBrains doesn't approve LSP4IJ 0.8.0 because I'm using ProjectIndexingActivityHistoryListener which is internal API. That's too bad! I need to fins a solution to track

• start/stop of dumb (it exists a DumbModeListener, I hope it is not internal)
• start / stop of file indexing (how to do that?) If someone have some idea how to do that, an idea are welcome!

[InSyncWithFoo]

@KUGDev Except for verifier false positives, new plugins with internal API usages won't be approved.

[KUGDev]

@InSyncWithFoo Understood. Never seen this rule before, but it sounds strange, cause some of the IntelliJ parts are impossible to modify appropriately without using internal APIs

[angelozerr]

@KUGDev it iscompatible, but JetBrains rejects the release -( I'm exploring to use the API with Java reflection because it seems that there is no way to track start/end of scannings files.

[KUGDev]

@angelozerr sometimes we use a workaround with the internal classes being declared in the repo itself. But it works only on the structures that are not too complicated (up to 3-4 classes) and that are possible to reuse as is

[angelozerr]

Hi, I merged my PR #633 by using horrible Java reflection.

Please try latest nightly build.

The version will be 0.8.1.

Before the release I would like to fix #634

[angelozerr]

@mrglavas I would like to recreate a new release as soon as possible,when I can do that (tomorrow, monday, other)?

[angelozerr]

@mrglavas I have some very interesting discussion on JetBrains Slack and here the answer:

• ProjectIndexingActivityHistoryListener must never used
• IntelliJ 2024.3 should fix a bug with smart mode. It should provide the capability to execute something when dum AND files scanning are finished. Before 2024.3 smart mode is execute just when dumb mode is inished but doesn't take car of scanning files.

I would like to investigate this morning that and if it works I will create a new nighthy. Hope it is OK for you.

[angelozerr]

@mrglavas it is too dangerous to change the code with the suggestion that I had in Jetbrains Slack. I will do that after the release. Please try the nighty.

[mrglavas]

@angelozerr Have there been any changes since yesterday? I was just reviewing our build results (the ones on Linux have been the most reliable).

Liberty Tools for IntelliJ (main) with LSP4IJ (main):
https://github.com/OpenLiberty/liberty-tools-intellij/actions/runs/12074471829

Liberty Tools for IntelliJ (24.0.9 - current release in Marketplace) with LSP4IJ (main):
https://github.com/OpenLiberty/liberty-tools-intellij/actions/runs/12074482933

I think these look good. These extracted whatever was on LSP4IJ (main) 20 hours ago.

We also have a cron job that runs daily which tests with the main branch and open PRs. This is the one from Thrusday:
https://github.com/OpenLiberty/liberty-tools-intellij/actions/runs/12066221383

I believe it started after our discussions yesterday. I see some compilation errors with PR 637, for example:

  symbol:   class ProjectIndexingManager
  location: package com.redhat.devtools.lsp4ij.client
> Task :compileJava
/home/runner/work/liberty-tools-intellij/liberty-tools-intellij/lsp4ij/src/main/java/com/redhat/devtools/lsp4ij/features/highlight/LSPTargetElementEvaluator.java:10: error: cannot find symbol
import com.redhat.devtools.lsp4ij.client.ProjectIndexingManager;

but I don't think this has been merged yet.

I have been manually testing with 0.8.1-20241128-131140 since yesterday and haven't encountered any issues. If there's nothing new since we last chatted, I think this is in good shape for a release. I hope JetBrains scan allows you to publish this time.

[angelozerr]

@mrglavas it is the same than yesterday

[angelozerr]

I believe it started after our discussions yesterday. I see some compilation errors with PR #637, for example:

@SCWells72 have fixed that. This PR will be merged after the release. You will not use this feature since your language servers doesn't provide implementation LSP support

[angelozerr]

I launched 0.8.1 release, lets wait for feedback from Jetbrains

[angelozerr]

0.8.1 should be now available on marketplace