lsp

robert-stuttaford 2025-08-08T05:26:38.005369Z

it seems there's there's a boolean being passed to clojure.core/name for some file in our large codebase. i am constantly seeing LSP :: Error from the Language Server: Internal error (Internal Error) errors. is there a simple way to track it down? (server log exception in thread) https://github.com/clojure-lsp/clojure-lsp/blob/master/lib/src/clojure_lsp/feature/document_symbol.clj#L23 typing code is quite laggy at the moment and i want to eliminate this as a possible cause

robert-stuttaford 2025-08-08T05:26:51.320909Z

2025-08-08T05:25:08.871Z  ERROR [clojure-lsp.server:60] - Error receiving message: Internal error (-32603)
{:id 169, :method "textDocument/documentSymbol"}
com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine       PlatformThreads.java:  872
com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine       PlatformThreads.java:  896
                java.util.concurrent.ForkJoinWorkerThread.run  ForkJoinWorkerThread.java:  188
                  java.util.concurrent.ForkJoinPool.runWorker          ForkJoinPool.java: 1806
                       java.util.concurrent.ForkJoinPool.scan          ForkJoinPool.java: 1841
     java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec          ForkJoinPool.java: 1310
                     java.util.concurrent.ForkJoinTask.doExec          ForkJoinTask.java:  387
      java.util.concurrent.CompletableFuture$AsyncSupply.exec     CompletableFuture.java: 1760
       java.util.concurrent.CompletableFuture$AsyncSupply.run     CompletableFuture.java: 1768
                                    promesa.util.Supplier/get                  util.cljc:   34
                                promesa.exec/wrap-bindings/fn                  exec.cljc:  163
                                    clojure-lsp.server/fn{x2}                 server.clj:  378
                         clojure-lsp.handlers/document-symbol               handlers.clj:  326
         clojure-lsp.feature.document-symbol/document-symbols        document_symbol.clj:  109
                                         clojure.core/sort-by                   core.clj: 3127 (repeats 2 times)
                                            clojure.core/sort                   core.clj: 3121
                                        clojure.core/to-array                   core.clj:  346
                                                          ...                                
                                          clojure.core/map/fn                   core.clj: 2770
 clojure-lsp.feature.document-symbol/element->document-symbol        document_symbol.clj:   23
                                            clojure.core/name                   core.clj: 1610
java.lang.ClassCastException: java.lang.Boolean cannot be cast to clojure.lang.Named

lassemaatta 2025-08-08T05:36:28.377379Z

just a hunch; are you using any clj-kondo hooks with clj-kondo.hook-api/reg-keyword!? A casual reading of the code implies it's trying to get the name of the :reg value, which I assume is provided by clj-kondo with that reg-keyword! mechanism. And for some reason the value is a boolean and not a keyword.

robert-stuttaford 2025-08-08T05:59:49.452729Z

@lasse.olavi.maatta thank you! we are doing exactly that! 😅 we have a 'defattr' schema system for which i set up a very simple custom hook to enable navigate-to-definition whenever you focus a given Datomic attribute:

(ns hooks.keyword
  (:require [clj-kondo.hooks-api :as api]))

(defn def-keyword [elem]
  (update-in elem [:node :children]
             (fn [[sym kwd spec]]
               [sym (api/reg-keyword! kwd true) spec])))
trying (api/reg-keyword! kwd :nonce) instead...

lassemaatta 2025-08-08T06:02:11.345629Z

I use reg-keyword! in one of our hooks as follows:

(api/reg-keyword! (-> (api/keyword-node (keyword (api/sexpr aname)))
                      (with-meta (meta aname)))
                  true)
and although I have no idea what I'm doing, it seems to work fine. I guess the relevant part is that I supply an actual keyword-node to the function.

robert-stuttaford 2025-08-08T06:02:39.886829Z

oh amazing, will try that variation too

robert-stuttaford 2025-08-08T06:06:38.043379Z

seems this worked, thanks @lasse.olavi.maatta!

👍 2