Closed byteit101 closed 3 years ago
Hello @ byteit101! 👋🏻
Sorry to hear that the plugin is not working as expected! Does Solargraph start up when you run in directly from a terminal (e.g. solargraph stdio
or solargraph socket
)?
If the above works, does the server get initialised with a "Solargraph initialized" message in socket mode? You can start it with solargraph socket
and perform the following command:
curl -X POST http://127.0.0.1:7658 -d '{"jsonrpc":"2.0","id":"1","method":"initialize","params":{"processId":10660,"rootPath":"/home/byteit101/rb/","rootUri":"file:///home/byteit101/rb/","capabilities":{"workspace":{"applyEdit":true,"workspaceEdit":{"documentChanges":true,"resourceOperations":["create","delete","rename"],"failureHandling":"undo"},"symbol":{"dynamicRegistration":true},"executeCommand":{"dynamicRegistration":true},"workspaceFolders":true},"textDocument":{"synchronization":{"willSave":true,"willSaveWaitUntil":true,"didSave":true},"completion":{"completionItem":{"snippetSupport":true,"documentationFormat":["markdown","plaintext"]}},"hover":{"contentFormat":["markdown","plaintext"]},"signatureHelp":{},"references":{},"documentHighlight":{},"documentSymbol":{"symbolKind":{"valueSet":[18,17,5,14,9,10,22,24,8,1,12,11,20,6,2,3,21,16,19,25,4,7,15,23,26,13]},"hierarchicalDocumentSymbolSupport":true},"formatting":{"dynamicRegistration":true},"rangeFormatting":{},"definition":{"linkSupport":true},"typeDefinition":{"linkSupport":true},"codeAction":{"codeActionLiteralSupport":{"codeActionKind":{"valueSet":["quickfix","refactor","refactor.extract","refactor.inline","refactor.rewrite","source","source.organizeImports"]}},"dynamicRegistration":true},"codeLens":{},"documentLink":{},"colorProvider":{},"rename":{}}},"clientName":"Eclipse Platform","trace":"off"}}'
Yes and yes:
$ solargraph socket
Solargraph is listening PORT=7658 PID=16721
warning: parser/current is loading parser/ruby25, which recognizes
warning: 2.5.8-compliant syntax, but you are running 2.5.1.
warning: please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.
[ANY] Solargraph initialized (3.0956502468325198 seconds)
Hmmm, I'm unsure why it would be working fine from the command line, but failing in Eclipse.
If you're up for spending a bit more time on the investigation, you could probably gather more information by launching the plugin in a developer environment. If you follow the instructions in the README, you'll be able to import the project in a suitable Eclipse distribution. By following the last bullet point in the README, you can then launch the project in a separate Eclipse Application and import some Ruby code in there. In the Console view of the first Eclipse instance (the one where you imported the project), you'll be able to see the Solargraph server logs! There may be something fishy in there, alternatively you may be able to step through some of the underlying LSP4E code invoked by the plugin. Let me know if this makes sense. :)
To start with, more NPE's:
!ENTRY org.eclipse.jface.text 4 0 2020-10-30 16:47:57.949
!MESSAGE java.lang.NullPointerException
!STACK 0
java.util.concurrent.CompletionException: java.lang.NullPointerException
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$UniCompose.tryFire(CompletableFuture.java:1081)
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)
Caused by: java.lang.NullPointerException
at org.eclipse.lsp4e.operations.color.DocumentColorProvider.isColorProvider(DocumentColorProvider.java:111)
at org.eclipse.lsp4e.LanguageServiceAccessor.lambda$15(LanguageServiceAccessor.java:590)
at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
... 6 more
java.util.concurrent.ExecutionException: java.lang.NullPointerException
at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
at org.eclipse.lsp4e.outline.EditorToOutlineAdapterFactory.getAdapter(EditorToOutlineAdapterFactory.java:64)
at org.eclipse.core.internal.runtime.AdapterManager.getAdapter(AdapterManager.java:339)
at org.eclipse.core.internal.runtime.AdapterManager.loadAdapter(AdapterManager.java:366)
at org.eclipse.core.runtime.Adapters.queryAdapterManager(Adapters.java:118)
at org.eclipse.core.runtime.Adapters.adapt(Adapters.java:81)
at org.eclipse.core.runtime.Adapters.adapt(Adapters.java:112)
at org.eclipse.ui.views.contentoutline.ContentOutline.doCreatePage(ContentOutline.java:135)
at org.eclipse.ui.part.PageBookView.createPage(PageBookView.java:369)
at org.eclipse.ui.part.PageBookView.partActivated(PageBookView.java:696)
at org.eclipse.ui.part.PageBookView$1.partActivated(PageBookView.java:1006)
at org.eclipse.ui.internal.WorkbenchPage$4.run(WorkbenchPage.java:4905)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.ui.internal.WorkbenchPage.firePartActivated(WorkbenchPage.java:4902)
at org.eclipse.ui.internal.WorkbenchPage.access$3(WorkbenchPage.java:4878)
at org.eclipse.ui.internal.WorkbenchPage$E4PartListener.partActivated(WorkbenchPage.java:219)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl$2.run(PartServiceImpl.java:249)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.firePartActivated(PartServiceImpl.java:246)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:770)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.switchPerspective(PartServiceImpl.java:638)
at org.eclipse.e4.ui.workbench.renderers.swt.PerspectiveStackRenderer.showTab(PerspectiveStackRenderer.java:102)
at org.eclipse.e4.ui.workbench.renderers.swt.LazyStackRenderer.postProcess(LazyStackRenderer.java:114)
at org.eclipse.e4.ui.workbench.renderers.swt.PerspectiveStackRenderer.postProcess(PerspectiveStackRenderer.java:64)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:677)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:765)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$0(PartRenderingEngine.java:736)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:730)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:714)
at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:71)
at org.eclipse.e4.ui.workbench.renderers.swt.SashRenderer.processContents(SashRenderer.java:148)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:673)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:765)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$0(PartRenderingEngine.java:736)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:730)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:714)
at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:71)
at org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer.processContents(WBWRenderer.java:667)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:673)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:765)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$0(PartRenderingEngine.java:736)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:730)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:714)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1083)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155)
at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:153)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:150)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:657)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:594)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
Caused by: java.lang.NullPointerException
at org.eclipse.lsp4e.outline.EditorToOutlineAdapterFactory.lambda$0(EditorToOutlineAdapterFactory.java:60)
at org.eclipse.lsp4e.LanguageServiceAccessor.lambda$15(LanguageServiceAccessor.java:590)
at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
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)
java.util.concurrent.CompletionException: java.lang.NullPointerException
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$UniCompose.tryFire(CompletableFuture.java:1081)
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)
Caused by: java.lang.NullPointerException
at org.eclipse.lsp4e.operations.codelens.CodeLensProvider.lambda$0(CodeLensProvider.java:41)
at org.eclipse.lsp4e.LanguageServiceAccessor.lambda$15(LanguageServiceAccessor.java:590)
at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
... 6 more
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155)
at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:153)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:150)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:657)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:594)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
Caused by: java.lang.NullPointerException
at org.eclipse.lsp4e.operations.completion.LSContentAssistProcessor.lambda$4(LSContentAssistProcessor.java:166)
at org.eclipse.lsp4e.LanguageServiceAccessor.lambda$15(LanguageServiceAccessor.java:590)
at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
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)
/usr/bin/env: ‘ruby_executable_hooks’: No such file or directory
^ I investigated this one further.
# Default = jruby-9.2.7.0
~ which ruby_executable_hooks >/dev/null && echo "yes" || echo "no"
no
~ rvm use ruby-2.5.1 ~ which ruby_executable_hooks >/dev/null && echo "yes" || echo "no"
yes
~ rvm use ruby-2.6.2
~ which ruby_executable_hooks >/dev/null && echo "yes" || echo "no"
no
~
These gemdirs have ruby or jruby executable hooks:
~/.rvm/gems/default/bin/jruby_executable_hooks
~/.rvm/gems/jruby-1.7.19/bin/jruby_executable_hooks
~/.rvm/gems/jruby-1.7.19@global/bin/jruby_executable_hooks
~/.rvm/gems/jruby-9.1.5.0@global/bin/jruby_executable_hooks
~/.rvm/gems/jruby-9.2.7.0/bin/jruby_executable_hooks
~/.rvm/gems/jruby-9.2.7.0@global/bin/jruby_executable_hooks
~/.rvm/gems/ruby-2.2.0/bin/ruby_executable_hooks
~/.rvm/gems/ruby-2.2.0@global/bin/ruby_executable_hooks
~/.rvm/gems/ruby-2.5.1/bin/ruby_executable_hooks
~/.rvm/gems/ruby-2.5.1@global/bin/ruby_executable_hooks
~/.rvm/gems/ruby-2.7.1/bin/ruby_executable_hooks
And my installs:
$ rvm ls
ext-truffleruby [ x86_64 ]
jruby-1.7.19 [ x86_64 ]
jruby-9.1.17.0 [ x86_64 ]
jruby-9.1.5.0 [ x86_64 ]
jruby-9.1.6.0 [ x86_64 ]
jruby-9.2.0.0 [ x86_64 ]
* jruby-9.2.7.0 [ x86_64 ]
jruby-head [ x86_64 ]
ruby-1.9.3-p327 [ x86_64 ]
ruby-2.2.0 [ x86_64 ]
ruby-2.3.1 [ x86_64 ]
=> ruby-2.5.1 [ x86_64 ]
ruby-2.6.2 [ x86_64 ]
ruby-2.7.1 [ x86_64 ]
ruby-head [ x86_64 ]
# => - current
# =* - current && default
# * - default
jruby had none until I did gem install executable-hooks
in jruby 9.2.7 (default).
jruby (has jruby*) is my default, 2.6.2 (has none) and 2.5.1 (has ruby*) are the ones I've been trying with eclipse-solargraph.
However, it looks like that gem is deprecated, so I removed it (handy, they have uninstall directions!), and instead got:
~ ~/.rvm/gems/ruby-2.5.1/bin/solargraph stdio
Gem::GemNotFoundException: can't find gem solargraph (>= 0.a) with executable solargraph
find_spec_for_exe at ~/.rvm/rubies/jruby-9.2.7.0/lib/ruby/stdlib/rubygems.rb:289
activate_bin_path at ~/.rvm/rubies/jruby-9.2.7.0/lib/ruby/stdlib/rubygems.rb:308
<main> at ~/.rvm/gems/ruby-2.5.1/bin/solargraph:23
because the shebang line was now just env ruby
. Luckily a rvm all-gemsets do gem pristine --all --only-executables
fixed that.
And now I'm at:
~ ~/.rvm/gems/ruby-2.5.1/bin/solargraph stdio
Traceback (most recent call last):
8: from ~/.rvm/gems/ruby-2.5.1/bin/solargraph:23:in `<main>'
7: from ~/.rvm/rubies/ruby-2.5.1/lib/ruby/2.5.0/rubygems.rb:309:in `activate_bin_path'
6: from ~/.rvm/rubies/ruby-2.5.1/lib/ruby/2.5.0/rubygems.rb:309:in `synchronize'
5: from ~/.rvm/rubies/ruby-2.5.1/lib/ruby/2.5.0/rubygems.rb:310:in `block in activate_bin_path'
4: from ~/.rvm/rubies/ruby-2.5.1/lib/ruby/2.5.0/rubygems/specification.rb:1440:in `activate'
3: from ~/.rvm/rubies/ruby-2.5.1/lib/ruby/2.5.0/rubygems/specification.rb:1458:in `activate_dependencies'
2: from ~/.rvm/rubies/ruby-2.5.1/lib/ruby/2.5.0/rubygems/specification.rb:1458:in `each'
1: from ~/.rvm/rubies/ruby-2.5.1/lib/ruby/2.5.0/rubygems/specification.rb:1469:in `block in activate_dependencies'
~/.rvm/rubies/ruby-2.5.1/lib/ruby/2.5.0/rubygems/dependency.rb:312:in `to_specs': Could not find 'jaro_winkler' (~> 1.5) - did find: [jaro_winkler-1.5.4-java] (Gem::MissingSpecVersionError)
Checked in 'GEM_PATH=~/.rvm/gems/jruby-9.2.7.0:~/.rvm/gems/jruby-9.2.7.0@global', execute `gem env` for more information
Which is a mix of jruby and mri. To launch with the right env, rvm-exec ruby-2.5.1 solargraph stdio
works just fine with the default jruby environment. I mentioned the debugging above as it might be something you might care to detect?
Thanks for the extra information!
It seems that most of the problems are coming from the JRuby setup. All the NPEs you're observing in the Eclipse plugin are simply symptoms of the underlying Gem failing at some point during initialisation. The author of the Solargraph gem has himself stated that:
Support for JRuby has been spotty, but I'd like to maintain it if possible
It may be worth filing an issue on the Solargraph repository and basically including all the non-Java investigation done here so far.
In parallel, one thing that could be done on the Eclipse plugin side would be to add some sort of preference to customise the language server startup command, so that users can prepend things such as rvm-exec ruby-2.5.1
to it. Not ideal though, as you mentioned automatically detecting the issue and taking care of it transparently would be better, but doing that from an external piece of Java code running in an Eclipse environment would be challenging.
All the NPEs you're observing in the Eclipse plugin are simply symptoms of the underlying Gem failing at some point during initialisation.
I would argue that, at a minimum they ought be caught and replaced in the UI with "error starting solargraph server" messages of some sort.
The author of the Solargraph gem has himself stated that:
Support for JRuby has been spotty, but I'd like to maintain it if possible
(sidenote, as a JRuby contributor: yay!)
It may be worth filing an issue on the Solargraph repository and basically including all the non-Java investigation done here so far.
I'm not sure what for? I just installed it on my jruby setup, and solargraph itself worked fine*, though the eclipse-solargraph plugin didn't know what to do with the WARNING: An illegal reflective access operation has occurred
warnings and kept restarting solargraph after every other context-assist.
Overall, I see 4 issues:
I haven't see any issues with solargraph itself.
* after I fixed the JVM issues, but that's neither here nor there
One thing that's probably useful to emphasise at this point is that eclipse-solargraph pretty much does nothing. It simply prepares a Java list containing two strings, ~/.rvm/gems/ruby-2.5.1/bin/solargraph
and stdio
, and hands them over to Eclipse when it asks for them. That's it. From that point onwards, it has no control over what is happening. There rest of the eclipse-solargraph code, and there isn't much of it, mostly relates to the debugger, the "Run as" launch configurations and some configuration for syntax highlighting. eclipse-solargraph really is a micro layer between Eclipse lsp4e and solargraph.
Now there is a possibility that the two aforementioned strings are incorrect or incomplete, but right now I'm unclear on what they should become.
eclipse-solargraph doesn't like RVM setups with solargraph being used on non-default installs.
One main difference between you starting Solargraph from your terminal and Eclipse lsp4e spawning a new child process using that same command is the environment. Eclipse won't be using a login shell, so any environment variables or RVM setup that occur when you you open a new terminal tab won't be happening here. One potential workaround would be to make eclipse-solargraph return four strings instead: /bin/bash
, -c
, -l
and ~/.rvm/gems/ruby-2.5.1/bin/solargraph stdio
. Do you have eclipse-solargraph setup in a dev environment? If so, could you please modify this line of and see if it changes anything at all: https://github.com/PyvesB/eclipse-solargraph/blob/5734c83b7c7fb7780677677ec92a3f24b5281d3f/eclipse-solargraph-plugin/src/main/java/io/github/pyvesb/eclipse_solargraph/server/SolargraphStreamConnectionProvider.java#L57
executable-hooks is a bad idea, and isn't portable between MRI/JRuby environments
I'm unsure what is requiring executable-hooks at this point. I'm guessing it would be the Solargraph gem itself?
eclipse-solargraph responds unfavorably to JRuby/JVM warnings by restarting solargraph needlessly
What is issuing those WARNING: An illegal reflective access operation has occurred
warnings? Is it JRuby? Where are you observing those logs and how did you come to the conclusion that they were the cause of the restart?
eclipse-solargraph doesn't disguise NPE's with a better warning.
This kind of comes back to my initial point about eclipse-solargraph's role. You'll notice that none of the stack traces mention this plugin, the exceptions are being thrown outside its control. There are a couple of related bugs opened on the lsp4e project (bug 508812 and bug 532701), it's probably worth upvoting or reacting on them. :)
see if it changes anything at all
Yes, changing that line makes it work fine
what is requiring executable-hooks at this point
Unsure why I had it installed myself. Nothing else depended on it. I'm guessing it was due to some old thing I had installed. Cruft.
What is issuing those WARNING: An illegal reflective access operation has occurred warnings?
The JVM itself.
how did you come to the conclusion that they were the cause of the restart?
When I replaced the solargraph command with a script that did solargraph stdio 2>/dev/null |tail -n +10
(to truncate the error messages at the start) eclipse-solargraph finally worked sucessfully
related bugs opened on the lsp4e project
Ah, good! (well, not "good", but you know what I mean)
Yes, changing that line makes it work fine
Thanks for checking, this probably mandates a change in eclipse-solargraph.
The JVM itself.
Just to be crystal clear, do you mean the JRuby JVM? Eclipse itself runs in a different JVM and could potentially be sending those warnings on the LSP stream.
When I replaced the solargraph command with a script that did
solargraph stdio 2>/dev/null |tail -n +10
(to truncate the error messages at the start) eclipse-solargraph finally worked sucessfully
I think I need to read what the LSP specification says about stderr, something somewhere is not handling things gracefully.
Just to be crystal clear, do you mean the JRuby JVM? Eclipse itself runs in a different JVM and could potentially be sending those warnings on the LSP stream.
Yes, the JRuby JVM. Unrelated to the Eclipse JVM. I have to look at them while working on JRuby stuff with Java 11
I've just pushed a commit that makes sure Solargraph is launched in a login shell, effectively running [/bin/bash
, -c
, -l
, "path-to-gem/solargraph" stdio
] on Unix systems and [cmd.exe
, /c
, "path-to-gem/solargraph" stdio
] on Windows. Tested on both my macOS and Windows laptops and you had also confirmed it worked by manually hardcoding the change. This will hopefully help users that have slightly more complex setups with things being specified in their _.bashprofile or similar places. Will release sometime next week. :)
I've also installed version 9.2.7.0 of JRuby. I did notice the An illegal reflective access operation has occurred
warnings as well, however they do not seem to prevent the language server from working. I could still happily use the Eclipse integration. It's worth noting that JRuby 9.2.7.0 is getting quite old and a quick search on GitHub indicates that a lot of these warnings were fixed in more recent versions (for example https://github.com/jruby/jruby/issues/6100, https://github.com/jruby/jruby/issues/6299 and https://github.com/jruby/jruby/issues/6189). Probably worth trying the latest version if you can.
Is there anything still outstanding on this issue?
Steps
Environment
Debian 10 x64 Ruby 2.5.1 solargraph (0.39.17) Eclipse 2020-09
Logs
The eclipse logs are filled with many copies of the below two entries
The language server logs are this, over and over again: