Clojurians Log v2

No, it was never requested, but sound like a good idea, feel free to create a issue

@ericdallo https://github.com/clojure-lsp/clojure-lsp/issues/2113

I can reproduce this. Is completion in namespaced maps supported by clojure-lsp, @ericdallo?

Repro:

;; foo.clj
(ns foo)

(defn foo [a b]
  (+ a b))

;; bar.clj
(ns bar
  (:require [foo :as foo]))

(def baz (foo/foo 1 2 3)) ;; should report wrong-arity

@borkdude correct me if I'm missing anything

Can confirm the same behavior with all src vs single

yeah, I tested a older kondo (jun) but same output with that repro, it's https://github.com/clojure-lsp/clojure-lsp/blob/17ca2df40b9166583e39efc91975fb733c66d08c/lib/src/clojure_lsp/kondo.clj#L343-L361 that enable kondo knows about other files, just need to remember (maybe cache: true?)

Also confirmed that the commands both return the error if it's a defn so it seems to be limited to def

So not just that it's single vs multiple

What's paining me personally about this is that Pedestal defines interceptors using def so it's not catching typos in any of them. In the meantime I'll need to remember to run the CLI command to check

can you summarize the issue for me?

Sure

Invalid arity errors are not showing in editors if in file b you call a function in file a, which is under a def

As simple as the repro above

can you make a repro as github repository so were talking about the same setup?

or do you mean something like:

(def a (comp whatever))

Literally just the repro above

What is "the repro above". I see a bunch of deleted file. Just give me a repro and I'll try. Don't have time to wade through threads to collect info

Eric's a few lines up

https://github.com/ericdallo/clojure-sample/blob/repro-kondo-cache/src/clojure_sample/bar.clj#L5

I'm trying to build a clj-kondo cli call but failing as clojure-lsp pass more args to it (need to include this on clojure-lsp doctor command )

so this right?

$ clj -M:clj-kondo/dev --lint - <<< '(defn foo [_ _]) (def x (foo/1 2 3))'
linting took 35ms, errors: 0, warnings: 0

sorry, typo.

$ clj -M:clj-kondo/dev --lint - <<< '(defn foo [_ _]) (def x (foo 1 2 3))'
<stdin>:1:25: error: user/foo is called with 3 args but expects 2
linting took 34ms, errors: 1, warnings: 0

$ clj -M:clj-kondo/dev --lint - <<< '(ns foo) (defn foo [_ _]) (ns bar (:require [foo])) (def x (foo/foo 1 2 3))'
<stdin>:1:60: error: foo/foo is called with 3 args but expects 2
linting took 36ms, errors: 1, warnings: 0

yeah, the point is: it works on same ns, but not different ones

only when using kondo cache

I know kondo doesn't have cache anymore, and that may be the issue

yes, the cache is necessary. clj-kondo does have a cache. just look in .clj-kondo/.cache. you're confusing it with something else, it doesn't cache some internal stuff about configuration which was for performance.

check https://clojurians.slack.com/archives/CBE668G4R/p1760981195216069?thread_ts=1756187184.228759&cid=CBE668G4R 2 bullet points, I believe without kondo cache, kondo is blind about the first linted previously file

ah got it

Well like I said it works in different ns if it's a defn

I can't reproduce with eric's repro.

/tmp/clojure-sample (repro-kondo-cache) $ clj-kondo --lint src/
src/clojure_sample/bar.clj:5:10: error: clojure-sample.foo/foo is called with 3 args but expects 2
linting took 15ms, errors: 1, warnings: 0

Yes, it works when linting src/

It does not when giving it the single file

ok, got it

Yeah, which is when kondo was supposed to read its cache, is that right?

it does have the right information cached:

$ jet --from transit < .clj-kondo/.cache/v1/clj/clojure-sample.foo.transit.json
{:filename "src/clojure_sample/foo.clj",
 foo {:arities {2 {:ret :number}},
      :col 1,
      :fixed-arities #{2},
      :name foo,
      :ns clojure-sample.foo,
      :row 3,
      :top-ns clojure-sample.foo,
      :type :fn}}

Yeah, I don't think it's a cache issue

Since it works when it's a defn instead of a def

can you make a github issue?

Sure

this does work:

(foo/foo 1 2 3)

(def baz (foo/foo 1 2 3))

it warns two times

I suspect some nasty laziness bug

yeah it was

This should fix it: https://github.com/clj-kondo/clj-kondo/compare/master...analyze-def-body

issue: https://github.com/clj-kondo/clj-kondo/issues/2641

What a simple fix. Gotta love those kind of bugs, haha

Thanks for taking a look into this promptly

This happened to me more often...

Oh, I'm sure

Fix PR: https://github.com/clj-kondo/clj-kondo/pull/2642

@borkdude I intend to bump clojure-lsp to latest kondo master when this is fixed, or are you do more testings in that PR?

I added tests in the PR, so should be good.

I'll merge when CI is green

Also I realized it's not just arity issues as I also noticed it not reporting that a function didn't exist from the other namespace that I had renamed to split it into 2 functions. So this will address multiple issues

merged

correct, it didn't report anything since all analysis was just waiting to be realized in a lazy seq

Makes sense

Pushed a clojure-lsp nightly

Can confirm with latest clojure-lsp nightly the analysis is correct 🙂

@pez I updated https://github.com/BetterThanTomorrow/calva/issues/2911 to reflect this

awesome!

This issue was open since August 27?

It was indeed

@ericdallo what made you revive this thread two days ago?

Me haha

@mike.j.cusack mentioned on our DM

The bug has been paining me working with Pedestal interceptors

ok. glad it's resolved

Yeah, thanks. I really appreciate the quick fix

Very nice!

I'll try clojure-lsp from the CLI

Sorry for the delay. With the same latest version installed it does report the error in CLI.

Thanks! I am out of ideas for now. This is quite the mystery. Please file an issue on Calva with the findings so far.

Ok. I can't at the moment, but later on when I'm free again I can do that. I won't include the screenshots though, but just explain the findings and include the version details.

Thanks. If the screenshots exclusion is for non-sharing reasons publicly, you should be aware that this slack is replicated to the web, so you may want to remove the screenshots here too. Just fyi.

Ah, yes. Good to know

@pez I haven't created the issue just yet since I'm trying to track down more specifically when it is happening. It seems like it's happening when the function being called belongs to another namespace. Calling standard lib functions, such as (map identity [1 2 3] [3 4 5]) inside of the let does show incorrect arity and unused var

The unused binding message is there for my earlier example, but not the arity message

Ah, very interesting. So I've narrowed it down to happening in a very specific case where the function call is happening inside of a let, inside of a fn, inside of a def . When it's just inside a let it works. When it's inside of the let and fn, but that's not inside a def then it works.

So trivial example:

(def baz
  (fn [input]
    (let [bar (other-ns/foo 1 2 3)])))

Where other-ns/foo is expected to only take 2 args

@pez https://github.com/BetterThanTomorrow/calva/issues/2911

No red squiggle or message in Calva.

From CLI

If the function is called outside of the let in addition to inside then Calva shows the message in both places. When the outside call is removed the message is removed from the let binding.

What clj-kondo version is Calva using for you? Calva reports this in the Output Channel Calva says at startup. The clj-kondo version in Calva a function of which clojure-lsp version is used, so that’s interesting too, as well as what your calva.clojureLspVersion config is set to.

Calva version used: v2.0.524
clojure-lsp version used: 2025.08.25-14.21.46
clj-kondo version used: 2025.07.28

clojure-lsp is set to the default of latest

I have the same clj-kondo version installed for CLI

Thanks. Maybe there’s some config for clojure-lsp that’s affecting this. Can you search the #lsp channel for any clues? Also I think we could get clojure-lsp to lint from the command line, trying to isolate if the issue is in Calva or clojure-lsp.