This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (8)
- # announcements (3)
- # beginners (36)
- # calva (1)
- # cider (1)
- # circleci (3)
- # clj-kondo (9)
- # cljdoc (58)
- # clojars (7)
- # clojure (70)
- # clojure-europe (13)
- # clojure-japan (1)
- # clojure-nl (8)
- # clojure-russia (2)
- # clojure-uk (7)
- # clojuredesign-podcast (4)
- # clojurescript (67)
- # clojureverse-ops (14)
- # cursive (6)
- # data-science (1)
- # datahike (3)
- # datomic (6)
- # docker (1)
- # events (2)
- # figwheel-main (9)
- # fulcro (4)
- # graalvm (33)
- # graphql (8)
- # helix (1)
- # jobs (1)
- # leiningen (3)
- # lsp (39)
- # malli (9)
- # minecraft (31)
- # nextjournal (7)
- # off-topic (6)
- # portal (22)
- # re-frame (5)
- # reitit (5)
- # remote-jobs (1)
- # shadow-cljs (55)
- # sql (22)
- # tools-build (3)
- # tools-deps (4)
- # xtdb (6)
is there any simple way of tracking down why I sometimes get false-positive
unused-public-var problems on functions, which are actually being called in my codebase?
We have a issue on cljc files that was ready fixed on kondo and it will be available on next clojure-lsp release, any chance your issue is related to cljc files?
=== duplicate-files [clj-kondo] Already seen the file /home/circleci/repo/corpus/simple_test/a_test.clj before, skipping
ok, merged to master. I will add a few more features to clj-kondo before announcing a new release (later this week or next week) but those are probably not so interesting for LSP
sorry, I wasn't around much today.
that issue I'm facing happens on regular clj files. I'm affraid I don't have an easy way to reproduce it easily. In fact I believe that there's a chance that the mentioned
unused-public-var false positive warning might even fix after I restart my running calva instance. That's why I wanted to check first whether I can try to analyse something on that running calva instance where the problem still shows.
For example I have
(ns someproject.util (:import [java.util UUID])) (defn uuid  (str (UUID/randomUUID)))
I can ctrl+click the
(ns someproject.db.someitem (:require [xtdb.api :as xt] [someproject.util :refer [uuid]])) ... (defn somefn! [xtdb-node some-id] (let [new-id (uuid)] ....
(uuid)and it navigates me correctly to
defn uuidfunction.. Everything works on runtime, but the editor shows unsused var warning on that "function definition side". When I run
then the output is clear.. no issues.
clj-kondo --lint src/clj
> In fact I believe that there's a chance that the mentioned `unused-public-var` false positive warning might even fix after I restart my running calva instance.
I can now confirm that. I simply made a copy of the whole folder of my app, opened it in yet another vscode/calva instance and the
uuid function is no longer shown as "unused". So I'm affraid makins repro doesn't seem to be an easy task. I have no idea how it happened, that I ended up in that strange situation where the fn is shown as unused - and restarting my editor (and calva/lsp) seems to fix the problem.
@U01LFP3LA6P clj-kondo itself doesn't have the unused-public-var linter, you have to use clojure-lsp for linting
just a small tip for those of us using
lsp-mode in emacs in a Clojure monorepo with a lot of
checkouts directories—i kept running out of file handles on my system because
lsp-mode was following symlinks to projects many times. adding
(add-to-list 'lsp-file-watch-ignored-directories "[/\\\\]\\checkouts\\'") to my emacs configuration remediated the issue
in Leiningen-based projects, yes https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#checkout-dependencies
if so, we should consider adding that to lsp-mode repo: https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-mode.el#L343
@U013GG71CHL LGTM, would you mind opening a PR on lsp-mode adding that to the link I sent?