MalformedTreeException: Overlapping text edits

[milic-marko]

After opening and importing project, navigating to a class and hovering over a method to display more information I got error below inlanguage server and tooltill was not showing.

Details

Error - 2:46:19 PM] Request textDocument/codeAction failed.
  Message: Internal error.
  Code: -32603 
java.util.concurrent.CompletionException: org.eclipse.text.edits.MalformedTreeException: Overlapping text edits
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
Caused by: org.eclipse.text.edits.MalformedTreeException: Overlapping text edits
	at org.eclipse.text.edits.TextEdit$InsertionComparator.compare(TextEdit.java:126)
	at org.eclipse.text.edits.TextEdit$InsertionComparator.compare(TextEdit.java:1)
	at java.base/java.util.Collections.indexedBinarySearch(Unknown Source)
	at java.base/java.util.Collections.binarySearch(Unknown Source)
	at org.eclipse.text.edits.TextEdit.computeInsertionIndex(TextEdit.java:799)
	at org.eclipse.text.edits.TextEdit.internalAdd(TextEdit.java:784)
	at org.eclipse.text.edits.TextEdit.addChildren(TextEdit.java:354)
	at org.eclipse.jdt.internal.corext.refactoring.code.SourceProvider.getCodeBlocks(SourceProvider.java:444)
	at org.eclipse.jdt.internal.corext.refactoring.code.CallInliner.perform(CallInliner.java:489)
	at org.eclipse.jdt.internal.corext.refactoring.code.InlineMethodRefactoring.checkFinalConditions(InlineMethodRefactoring.java:316)
	at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:86)
	at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:116)
	at org.eclipse.jdt.ls.core.internal.corrections.RefactorProcessor.getInlineProposal(RefactorProcessor.java:388)
	at org.eclipse.jdt.ls.core.internal.corrections.RefactorProcessor.getProposals(RefactorProcessor.java:145)
	at org.eclipse.jdt.ls.core.internal.handlers.CodeActionHandler.getCodeActionCommands(CodeActionHandler.java:205)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$14(JDTLanguageServer.java:758)
	at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)
	... 7 more

[rgrunber]

What version of JDT-LS was this ? Were you using vscode-java as the client extension ? Was it a pre-release of vscode-java ?

Update: Based on the stacktrace it looks like v1.41.0, so last release

[milic-marko]

Hi @rgrunber , this was with
vscode-java: 1.36.0
vscode: 1.95.3

It was not prerelase. Though the error was gone after the restart fo vscode.

[rgrunber]

@snjeza now that I look closer I realize this is happening in the Eclipse based text edits (not our code producing the lsp4j ones) so might be an upstream issue. @mamilic , if you have a consistent way to reproduce it, could you try one of our vscode-java pre-releases to see if the problem still occurs there. It might be an upstream problem but we changed the way we do inline refactorings very recently ( #3322 ).

We deferred the actual text edit computation to codeAction/resolve (when the item is chosen) as opposed to textDocument/codeAction (when they're all listed). This should at least reduce the likelihood of it happening to only when selected. However, if there's something odd going on with the sources, maybe this eliminates the issue entirely.

Update: Also, if you're able to share the project/source file where this happens, that would help.

[milic-marko]

@rgrunber I could not reproduce this at all after that single occurence. Well, I would say without reproducible sample there is not much it can be done for this.