Not currently - you could however use the analysis output and scan for it manually using a script

Hm yeah, but then I wouldn't get warnings in my editor which is kind of the motivation. No problem though, just thought I'd ask 🙂 thanks for the quick response!

I guess one thing that might be possible is a function linter that checks literal keywords in a map that's passed to it?

command:

clojure -M:clj-kondo --lint "$(clojure -Spath)" --dependencies --parallel
clojure -M:clj-kondo --fail-level error --lint src --lint test --lint plugins

{:replace-deps {clj-kondo/clj-kondo {:mvn/version "RELEASE"}}
                         :main-opts ["-m" "clj-kondo.main" ]}

Exception in thread "pool-1-thread-3" java.lang.OutOfMemoryError: Java heap space
        at clojure.lang.ArraySeq.next(ArraySeq.java:78)
        at clojure.lang.RT.next(RT.java:713)
        at clojure.core$next__5451.invokeStatic(core.clj:64)
        at clojure.core$second__5457.invokeStatic(core.clj:98)
        at clojure.core$assoc__5481.invokeStatic(core.clj:197)
        at clojure.core$assoc__5481.doInvoke(core.clj:192)
        at clojure.lang.RestFn.invoke(RestFn.java:731)
        at clj_kondo.impl.types$add_arg_type_from_call.invokeStatic(types.clj:390)
        at clj_kondo.impl.types$add_arg_type_from_call.invoke(types.clj:387)
        at clj_kondo.impl.analyzer$analyze_expression_STAR__STAR_.invokeStatic(analyzer.clj:2977)
        at clj_kondo.impl.analyzer$analyze_expression_STAR__STAR_.invoke(analyzer.clj:2799)
        at clj_kondo.impl.analyzer$analyze_children$fn__14975.invoke(analyzer.clj:77)
        at clojure.core$map_indexed$fn__8634$fn__8635.invoke(core.clj:7366)
        at clojure.lang.ArrayChunk.reduce(ArrayChunk.java:58)
        at clojure.core.protocols$fn__8244.invokeStatic(protocols.clj:136)
        at clojure.core.protocols$fn__8244.invoke(protocols.clj:124)
        at clojure.core.protocols$fn__8204$G__8199__8213.invoke(protocols.clj:19)
        at clojure.core.protocols$seq_reduce.invokeStatic(protocols.clj:31)
        at clojure.core.protocols$fn__8236.invokeStatic(protocols.clj:75)
        at clojure.core.protocols$fn__8236.invoke(protocols.clj:75)
        at clojure.core.protocols$fn__8178$G__8173__8191.invoke(protocols.clj:13)
        at clojure.core$transduce.invokeStatic(core.clj:6947)
        at clojure.core$into.invokeStatic(core.clj:6962)
        at clojure.core$into.invoke(core.clj:6950)
        at clj_kondo.impl.analyzer$analyze_children.invokeStatic(analyzer.clj:75)
        at clj_kondo.impl.analyzer$analyze_children.invoke(analyzer.clj:50)
        at clj_kondo.impl.analyzer$analyze_children.invokeStatic(analyzer.clj:52)
        at clj_kondo.impl.analyzer$analyze_children.invoke(analyzer.clj:50)
        at clj_kondo.impl.analyzer$analyze_fn_body.invokeStatic(analyzer.clj:511)
        at clj_kondo.impl.analyzer$analyze_fn_body.invoke(analyzer.clj:459)
        at clj_kondo.impl.analyzer$analyze_defn$fn__15161.invoke(analyzer.clj:652)
        at clojure.core$map$fn__5935.invoke(core.clj:2772)

do you have a repro that I can run locally?

Sorry, I can't reproduce it locally 😞

It could be a bug in the new release, but without a repro it's hard to confirm that... Perhaps you can lower the memory with

-Xmx2048m

Nope, still can't reproduce... In fact the new version seems to behave better on my machine at 512MB. I don't think there's anything you can do with this information... We've bypassed the issue by pinning clj-kondo to the previous version (`2024-02-12`), so it's not a big deal (for now). I've marked this as resolved. Thanks for your help 🙂

so you'll stay on 2024-02-12 forever now? ;)

@UEQPKG7HQ I think I may have found where the issue could be coming from. Are you using clj-kondo on the JVM in CI? If so, could you please test with commit:

c1780ac6308edebbefa9745d0887442c9964b99a

ace53daa65afe251354c331c74c334df6beb877a

you can also try the binaries for those commits, I can link you to those binaries

so you'll stay on 2024-02-12 forever now?Why not? It's good enough 😄 > could you please test with commit Just did; c1780a works, ace53d doesn't! (on CI, still can't reproduce locally)

yeah I suspected so. I will try to make a fix and then you can try the new commit

Alright, try commit 99650c58bb8df990d6c28d8b554d84df6608ad4c

It works, thanks a lot! 🙂

Curious, what was the issue?

Too many large hash-maps in memory

Maybe just change nil to a number?

but I need the nil, which means that option hasn't been set

alternatively you can prefix the offending form with #_:clj-kondo/ignore

but in this case I guess I can assign a default number which means no number

thanks!

If it's a thing that you're updating, why not use a promise?

(def possibly-a-number (promise))

(defn some-check []
  (and (realized? possibly-a-number) (< @possibly-a-number 42)))

(defn initialise []
  (deliver possibly-a-number 12)
  nil)

(comment

  (some-check) ;; => false

  (initialise) ;; => nil

  (some-check) ;; => true

  )

or an atom?

just semantics. That was a contrived example, not my exact code. It is a thing that will be nil for most users but you can put a number there once if you need a different behavior. A promise conveys that something will be delivered there eventually, and an atom that is a value that is supposed to change so you need to constantly deref. Since you are constantly derefing the var, a simple var is enough for this, doesn't need a reference inside a reference.

to solve this generally, clj-kondo would have to become a fully-fledged type inference engine lol