Do kondo "evaluate"/"understand" clojure.spec in some way? can it lint things like

(s/def ::f (s/nilable fn?))
(let [{::keys [f]} env]
  (f))

@souenzzo I'll paste something out of a conversation I had in #clojure-spec:

Slack: borkdude: Yes. spec is a runtime validation/conformation/generation library. And considering how complex core.typed gets, I don't think getting leverage out of specs at compile time is trivial. Using a tool for something it's not designed for in general is ... hard.

Slack: borkdude: I do think you can get <some> leverage out of it. E.g. a tool could inspect specs at runtime, parse out the trivial stuff like, is the first argument an int?? Then something like  can be generated and you will get <some> static analysis benefits for clj-kondo, for example.

borkdude: Malli / @ikitommi has demoed a similar approach at ClojureD.

jahvenni: Yeah, figuring out the trivial stuff is what I had in mind mostly. I can see many trivial cases where a linter utilising specs could easily provide value. Things like order of parameters, names of keyword arguments or tricky get-in's are mentally really heavy for someone who is used to have these things given by autofill. To me these sound like trivial things to check in most cases if spec is provided. It would be a much softer landing to a dynamic language.

here’s the prototype from clj-kondo + malli

Just merged support for linting in parallel which can give significant speedups when you are linting an entire classpath. https://github.com/borkdude/clj-kondo/issues/632