Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

End of File exception when opening completion in empty file #1611

Closed
datho7561 opened this issue Nov 24, 2020 · 1 comment · Fixed by #1614
Closed

End of File exception when opening completion in empty file #1611

datho7561 opened this issue Nov 24, 2020 · 1 comment · Fixed by #1614

Comments

@datho7561
Copy link
Contributor

jdt.ls: 0.71.0
VSCode:
1.51.1
e5a624b788d92b8d34d1392e4c4d9789406efe8f
x64

When opening completion at the end of a file with only whitespace, an Exception gets logged:

End Of File
org.eclipse.core.runtime.CoreException: End Of File
	at org.eclipse.jdt.internal.corext.dom.TokenScanner.readNext(TokenScanner.java:153)
	at org.eclipse.jdt.internal.corext.dom.TokenScanner.readNext(TokenScanner.java:191)
	at org.eclipse.jdt.ls.core.internal.contentassist.SnippetCompletionProposal$SnippetCompletionContext.needsPublic(SnippetCompletionProposal.java:116)
	at org.eclipse.jdt.ls.core.internal.contentassist.SnippetCompletionProposal$SnippetCompletionContext.needsPublic(SnippetCompletionProposal.java:97)
	at org.eclipse.jdt.ls.core.internal.contentassist.SnippetCompletionProposal.getClassSnippet(SnippetCompletionProposal.java:336)
	at org.eclipse.jdt.ls.core.internal.contentassist.SnippetCompletionProposal.getTypeDefinitionSnippets(SnippetCompletionProposal.java:273)
	at org.eclipse.jdt.ls.core.internal.contentassist.SnippetCompletionProposal.getSnippets(SnippetCompletionProposal.java:191)
	at org.eclipse.jdt.ls.core.internal.handlers.CompletionHandler.computeContentAssist(CompletionHandler.java:156)
	at org.eclipse.jdt.ls.core.internal.handlers.CompletionHandler.completion(CompletionHandler.java:79)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$4(JDTLanguageServer.java:514)
	at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:75)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:642)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)

I was able to reproduce this in a Maven project and also with a standalone Java file. The snippets appear to work file though.

@rgrunber
Copy link
Contributor

rgrunber commented Nov 25, 2020

I'm also able to reproduce.

The problem seems to be a mismatch between what TokenScanner does and what JDT-LS expects. JDT-LS wants to read the token, and if ITerminalSymbols.TokenNameEOF is returned , then it will perform some other actions. However, TokenScanner doesn't seem to ever return ITerminalSymbols.TokenNameEOF. If it encounters EOF it simply throws a CoreException with status code TokenScanner.END_OF_FILE .

We can probably just adjust the segment where we catch the CoreException to verify if it is due to EOF and recover accordingly.

rgrunber added a commit to rgrunber/eclipse.jdt.ls that referenced this issue Nov 25, 2020
- Fixes eclipse-jdtls#1611
- TokenScanner.readNext(..) throws CoreException with appropriate code
  when EOF is reached instead of returning TokenNameEOF so the
  exception logging should be suppressed in this case

Signed-off-by: Roland Grunberg <rgrunber@redhat.com>
testforstephen pushed a commit that referenced this issue Nov 26, 2020
- Fixes #1611
- TokenScanner.readNext(..) throws CoreException with appropriate code
  when EOF is reached instead of returning TokenNameEOF so the
  exception logging should be suppressed in this case

Signed-off-by: Roland Grunberg <rgrunber@redhat.com>
@testforstephen testforstephen added this to the End November 2020 milestone Nov 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants