Fork me on GitHub
#lsp
<
2024-05-22
>
andrea.crotti11:05:57

has anyone seen (error lsp-execute-command is already defined as something else than a generic function) ?

ericdallo11:05:08

looks like a bad emacs compilation

andrea.crotti11:05:15

I had this problem as well, and that setnev trick worked I think

andrea.crotti11:05:25

but I can try to clean the eln-cache again

andrea.crotti11:05:17

yeah no still happening, so probably it's just because of that then

⛔ Error (use-package): fancy-narrow/:catch: Native compiler error: (lambda (&optional) (let ((f #'point-min)) (funcall f))), "Compiling /Users/andrea/.emacs.d/eln-cache/29.3-7b39e62b/subr--trampoline-706f696e742d6d696e_point_min_0.eln...
ld: library 'emutls_w' not found
libgccjit.so: error: error invoking gcc driver
Internal native compiler error: \"failed to compile\", \"/Users/andrea/.emacs.d/eln-cache/29.3-7b39e62b/subr--trampoline-706f696e742d6d696e_point_min_0.eln\", \"error invoking gcc driver\"

andrea.crotti11:05:50

funnily enough I switch to emacs-plus@30 which fixed some other issues with LSP. The LSP problems were solved but I had other problems with v30 so I switched back to 29 and now it seems broken entirely 😕

dominicm15:05:33

We've just added this to our clj-kondo/config.edn, and it's stopped clojure-lsp from working properly 😄 :

:ns-groups [{:filename-pattern "test/.*" :name test-group}]
it works OK with :pattern "..." :name ... variants though. I can't see an open issue about this, nor an obvious cause in the code.

borkdude15:05:22

Does clj-kondo on the command line still work?

dominicm15:05:01

Files run through with clj-kondo --lint ... seem fine, yeah

dominicm15:05:53

It runs through analysis OK, too

dominicm16:05:20

Trying to work on this locally, but my jar build of the cli just keeps running out of heap space... Is there a guide anywhere to developing clojure-lsp locally?

dominicm16:05:02

ah, figured it out. Xmx2g is hardcoded, changing it to 6g solved it 🙂

👍 1
ericdallo16:05:26

I can't see how this could be a clojure-lsp issue :thinking_face:, maybe it's a clj-kondo issue but it needs speicfic args that clojure-lsp passes to it

dominicm16:05:50

My only thought so far is that filename is being passed as nil, and that's causing a (silent?) exception.

dominicm16:05:11

My attempts at println-debugging this are being thwarted so far though 😄

ericdallo16:05:43

you should use logger/info in clojure-lsp

dominicm16:05:02

I tried that, but got a compile error: No single method: _warn of interface: clojure_lsp.logger.ILogger found for function: -warn of protocol: ILogger

1
dominicm16:05:46

I'm guessing the point at which kondo-config-for-ns is called isn't appropriate to log?

dominicm16:05:58

I had a few symbols on the end too, but yes

dominicm16:05:06

aha, I think my filename theory is correct, though!

ericdallo16:05:14

I think it doesn't support too many args, try to concat the args

dominicm16:05:34

The docstring is & args and other uses I saw did that, but I shall give it a try

dominicm16:05:58

But, this diff "fixes" the problem:

diff --git a/lib/src/clojure_lsp/feature/diagnostics.clj b/lib/src/clojure_lsp/feature/diagnostics.clj
index dc9033f7..8e8d6268 100644
--- a/lib/src/clojure_lsp/feature/diagnostics.clj
+++ b/lib/src/clojure_lsp/feature/diagnostics.clj
@@ -33,7 +33,7 @@
   #{:deprecated-var})
 
 (defn ^:private kondo-config-for-ns [kondo-config ns-name filename]
-  (let [ns-groups (cons ns-name (kondo.config/ns-groups kondo-config ns-name filename))
+  (let [ns-groups (cons ns-name (kondo.config/ns-groups kondo-config ns-name (or filename "")))
         configs-in-ns (seq (keep #(get (:config-in-ns kondo-config) %) ns-groups))
         kondo-config (if configs-in-ns
                        (apply kondo.config/merge-config! kondo-config configs-in-ns)

dominicm16:05:48

(maybe that's broken, too?)

ericdallo16:05:11

yeah, we should fix it, the defprotocol doesn't support & args IIRC

dominicm16:05:39

Yeah, I see what you mean. Looks like that log would break if it ever got hit.

dominicm16:05:45

Not sure why it compiles & mine doesn't...

dominicm16:05:37

Using str fixed the compile, thanks!

dominicm16:05:05

Next question, where do those logs go? My attempts at getting a printout using

❯ /Users/dominicmonroe/src/github.com/clojure-lsp/clojure-lsp/clojure-lsp --log-path lsp.out references --from some.util/cond+
Haven't worked, lsp.out doesn't exist.

dominicm16:05:30

It didn't work after references, either.

ericdallo16:05:08

hum, it's supposed to work after references

ericdallo16:05:19

usually, I have this:

ericdallo16:05:45

~/.config/clojure-lsp/config.edn

{:log-path "/tmp/clojure-lsp.out"}

ericdallo16:05:51

so I don't need to pass that all the time

dominicm16:05:16

I shall do that, not trying to fix that right now 😄

dominicm16:05:56

Hmm.. no luck!

dominicm16:05:19

--verbose works, though!

dominicm16:05:51

Yep, filename is always being passed as nil

dominicm16:05:36

huh, using --verbose also got the file to populate...

dominicm16:05:00

OK, so looks like definitions have a :uri, but not a :filename.

dominicm16:05:01

I'm a bit confused by that, because presumably these are references from the kondo analysis, which I would assume have a :filename @U04V15CAJ?

ericdallo16:05:37

yeah, ideally clj-kondo would return URI for everything, but it returns filename, so we convert at lsp side

dominicm16:05:04

I guess when passing this into kondo then it should actually be (-> element :filename shared/uri->filename)?

dominicm16:05:03

s/:filename/:uri, rather 😄

dominicm16:05:50

Cool! Is it desirable to have the project root passed in somehow so it's relative like kondo would usually be? Though all the examples for :filename-pattern do lead with .* presumably to offset that different things happen at different times.

ericdallo16:05:46

I don't think so, filename is absolute path in all clojure-lsp places

dominicm16:05:06

Cool, in that case, fixed!

ericdallo16:05:04

feel free to open a PR so I can take a closer look later

ericdallo16:05:13

Ideally with a issue

dominicm16:05:19

I opened a PR, but not an issue.