This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-11
Channels
- # announcements (5)
- # babashka (43)
- # beginners (78)
- # calva (1)
- # cider (35)
- # clj-kondo (15)
- # clj-otel (3)
- # cljs-dev (2)
- # clojure (24)
- # clojure-denmark (1)
- # clojure-dev (9)
- # clojure-europe (43)
- # clojure-israel (1)
- # clojure-italy (1)
- # clojure-losangeles (3)
- # clojure-nl (1)
- # clojure-norway (54)
- # clojure-romania (1)
- # clojure-uk (2)
- # clojurescript (1)
- # core-async (25)
- # cursive (7)
- # datascript (6)
- # datomic (7)
- # docker (2)
- # emacs (2)
- # events (8)
- # exercism (2)
- # fulcro (2)
- # hyperfiddle (16)
- # lsp (46)
- # malli (10)
- # membrane (2)
- # music (6)
- # nbb (30)
- # off-topic (49)
- # polylith (4)
- # reagent (3)
- # releases (4)
- # shadow-cljs (5)
- # slack-help (1)
- # sql (2)
- # testing (2)
- # timbre (6)
- # tools-deps (29)
- # xtdb (36)
Out of curiosity, what enables clojure-lsp
to be able to lint unused public vars, that is beyond the scope of clj-kondo
? 🙂
Am I understanding correctly that clj-kondo has all the necessary information, but :unused-public-vars
is not wanted along with all the other linters of clj-kondo?
@U07FCNURX clj-kondo doesn't run as a server process and as such it doesn't have an overview of your whole project at one time, so it's hard to keep track of unused public vars that way. but it does provide the information necessary for more project-focussed tools that run as a server or a command line tool, like clojure-lsp or https://github.com/borkdude/carve
clj-kondo could do this but it would only work when you would say: clj-kondo --lint dir
and then it would tell you the unused public vars from the directory
You can read about the info that clj-kondo provides here: https://github.com/clj-kondo/clj-kondo/blob/master/analysis/README.md
I see that `clojure-lsp/unused-public-var` already has quite a few exclude
-options, but here's a question about another one: Any way to not lint this when used inside a (comment
-block?
(comment
(def just-testing-some-stuff ,,,))
we don't have options for that but sounds like a good improvement indeed, @U04V15CAJ do we have any way to know if a elemnt is inside a comment? otherwise that may affect performance check each unused-public-var if it's inside a comment
clj-kondo does have this information internally, but not sure if it's exposed through the analysis
@UKFSJSM38 since you create call hierarchies in lsp, don't you already have this information actually?
no, we don't have rewrite-clj nodes available in the analysis to know that, only kondo analysis, we parse rewrite-clj nodes only when we really need it, and we don't need to know call hierarchy
yes, that's how it works when you call call hierachy, we check the kondo analysis, but not rewrite node
yes, so why not check kondo analysis when you need to know if some call happened inside a comment
but if we don't have comment in analysis we can't do that right? that's my suggestion, to include in clj-kondo analysis
my point in short is: you have the information you need, else you wouldn't be able to create these call hierarchies. just use that information for your linter.
I don't get it why call hierarchy is related to inside-comment?
analysis, my point is, checking a var-usage
there is no way to know that var-usage is inside a comment without checking for other var-usages
of that ns + comparing locs to know if it's inside of that comment, or parsing rewrite-clj nodes of that ns.
the most viable is to compare locs of a comment
var-usage to know if current element is inside it
no, you DON'T need. it's happened several times now in this thread that you seem to be saying the exact opposite of what I would logically expect :)
> the most viable is to compare locs of a comment
var-usage to know if current element is inside it
indeed, that seems pretty reasonable to me
include a :inside-comment?
field on only var-usages that are inside a comment seems to be an option that affects less performance IMO
what is next: inside-defn
, inside-my-custom-namespace/foobar
, adding a field for every "inside this or that" would get things a little bloated.
For the 1000 public vars, you will maybe have 10 or 20 unused public vars, doing the extra location check only for those candidates, how would that affect performance badly? I have a hard time imagining that. but now I really gotta run
we can do a test with a big repo but knowing how complex is that linter already, I suspect it may happen a performance issue
@UKFSJSM38 this is the internal representation that clj-kondo has of a so-called "callstack":
$ clj -M:clj-kondo/dev --lint - <<< '(comment (def x. 1))'
([clojure.core def] [clojure.core comment])
x.
linting took 49ms, errors: 0, warnings: 0
When you define a var, the first element is def
and then comment
- this format is only used internally so far, but could perhaps be exposed (probably as maps though, instead of vectors)I'm making use of :paths-ignore-regex
to remove paths I don't care to be analyzed. However it does not seem to be used for filtering which directories will be watched. Is there any way to control this via a configuration parameter?
the watch configuration is completly done on client side (editor), for emacs lsp for example there is the lsp-file-watch-ignored-files
and lsp-file-watch-ignored-directories
@U0ESP0TS8 this means you can add your own directories like this:
(add-to-list 'lsp-file-watch-ignored-directories
"[/\\\\]\\.git\\'")
There's a whole bunch of escaping going on, courtesy of emacs lisp regex shenanigans, but if you squint, you can see where to add your directories. 😅