lsp 2022-09-10 | Slack Archive

armed05:09:47

LSP noob question. Trying to get it working with java sources in neovim (native lsp without coc.nvim). I keep getting following error when trying to navigate to external java sources:

{ 
  error = 
  { 
    code = -32603, 
    data = { 
      id = 80, 
      method = "textDocument/definition" 
    },
     message = "Internal error" 
  },
  id = 80,
  jsonrpc = "2.0"
}

armed05:09:06

I get this error when trying to navigate to external non core java libraries. But JDK sources returns "No location found"

ericdallo13:09:35

Could you check server logs especially after initialization?

armed10:09:19

@ericdallo turned on trace, and restarted LSP: https://gist.github.com/armed/4c23005fbf134c4c118d85b80114fe3e

armed10:09:00

and this is what happening when I go to definition on non core java dependency: https://gist.github.com/armed/501e8153d438483f2333c286df2f3437

armed10:09:52

java core souce (e.g. BufferedReadStream): https://gist.github.com/armed/d747b5276466f0ddf9e9e992ebcd88dd

armed10:09:44

I’m using asdf tool to manage directory based JDK versions, can this affect? As soon as I cd to the project directory JAVA_HOME and java bin path changes to configured version

ericdallo13:09:10

@U34K4458X sorry, I meant this https://clojure-lsp.io/troubleshooting/#server-log Also, before re-try could you try rm -rf ~/.cache/clojure-lsp/

armed13:09:50

@ericdallo ah, ok. Actually it started jumping to java sources after I removed cache dir. But still throws exception when I try to jump to google.guava deps. Logs say something about zip format. https://gist.github.com/armed/74e6de58d8b4b87b52cd9d643ad289ab

armed13:09:36

So my cache dir was somehow broken? Can this be because I change JDK version from project to project?

ericdallo13:09:58

Not sure @U34K4458X 😅 if that start to happens again LMK About the exception, looks weird indeed, from log it seems related with formatting code with cljfmt, did you call format from your editor?

armed13:09:23

I didn’t call format when recorded that logfile, but when I run lsp format all works fine. and that “The URL protocol zipfile is not tested and might not work as expected.” occurs only on one of the dependencies, weird.

ericdallo13:09:30

Oh, there is another exception later on

armed13:09:30

com.google.guava/guava {:mvn/version "31.1-jre"} this one

ericdallo13:09:48

@U34K4458X I think is related with https://github.com/clojure-lsp/clojure-lsp/blob/master/lib/src/clojure_lsp/feature/java_interop.clj#L104

ericdallo13:09:00

I think there must be a fix not that hard for that, please open a issue with a detailed repro so we can take a look later

ericdallo13:09:21

only vim uses zipfile AFAIK, all other clients use jar

armed13:09:39

wow, TIL

ericdallo13:09:59

yeah, pretty tricky

armed13:09:12

At leas I know the reason now. feeling much better )) I’ll create a repo with all the stuff to reproduce and open an issue

ericdallo13:09:25

thanks!

armed13:09:25

thanks

ericdallo16:09:37

@U34K4458X created a branch which should fix the issue, could you test it please? https://github.com/clojure-lsp/clojure-lsp/pull/new/fix-zipfile-class-decompilation Just clone clojure-lsp and run bb debug-cli to build a local clojure-lsp executable

armed18:09:26

Compiled from that branch, replaced existing binary. Still getting that error. Minimal repo: https://github.com/armed/lsp-nvim-zip-issue/

armed18:09:32

Calva works fine

armed18:09:08

@ericdallo it shows same version as release though

ericdallo18:09:32

calva uses jar scheme so it's not the same way vim uses, are you sure coc/nvim is using that clojure-lsp? The version output is not reliable for dev local builds unfortunately

ericdallo18:09:43

Does the exception is the same?

armed18:09:47

armed18:09:59

yep, this one ☝️

ericdallo18:09:26

Hum, this exceptions seems like a different bug I know how to fix, but it should happen only on native-images compiled with Graal, not via bb debug-cli

armed18:09:36

I’m not using coc.nvim, using native lsp. And I simply replaced nvim’s binary with compiled one

ericdallo18:09:39

Hum, weird, that exception is only for native ones

armed18:09:47

hmm, ok so I might be replaced the wrong one. But I double checked by deleting binary and nvim’s lsp stopped working. So the path is right imo.

armed18:09:25

Take it with grain of salt, I’m new to nvim.

armed18:09:02

Ok found another location binary. replacing

armed18:09:04

yes, it works (the compiled one). sorry for confusion.

armed18:09:19

@ericdallo

armed18:09:32

the bug is fixed in that branch

ericdallo18:09:28

Great! Will merge it so, thanks for testing it

armed18:09:22

Thank you for making clojure DX so great! I’m happy as never today. Now I can use nvim as a daily driver without any quirks.

ericdallo18:09:20

You're welcome! Glad it works!

borkdude09:09:38

lsp-organize imports removes imports that are necessary for some macro to work. I annotated them with:

#_:clj-kondo/ignore
   ["fs" :as fs]
   #_:clj-kondo/ignore
   ["path" :as path]

but lsp still removes them. Maybe lsp can take into account: when clj-kondo does not report the ns as unused, it should not be removed? /cc @ericdallo

ericdallo13:09:04

We rely on kondo findings for that IIRC, so I would expect to not remove, maybe a bug, is that your code snippet enough for the repro?

borkdude13:09:55

If you put an ns + require in a cljs file then yes

ericdallo13:09:38

Right, I can take a look soon

borkdude13:09:56

I should probably upgrade my lsp- the newest one is based on the Clojure rewrite right? Does it also do the lazy analysis by default? How's the stability been?

ericdallo13:09:24

Yes! So far no complains 🤞

🎉 2

ericdallo13:09:46

I'd expect some issues and people complaining here if there was a critical bug

borkdude09:09:39

@ericdallo I tested with the newest one and the issue persisted: https://github.com/clojure-lsp/clojure-lsp/issues/1237

👍 1

2022-09-10

Channels