Fork me on GitHub
#clj-kondo
<
2020-04-11
>
fabrao00:04:52

Hello all, I´m using Atom with clj-kondo, and, is this used to fix the warning/error from editor too, or only to tell?

seancorfield01:04:22

Linters just tell you what is wrong. How you fix them is up to you 🙂

fabrao01:04:31

I thought it was click to fix integration like in Visual Studio :-)

seancorfield01:04:45

I've never been comfortable with tools changing my code!

suomi.esko05:04:19

To be fair, IntelliJ IDEA's autofixes are numerous and extremely useful on the Java side. The bigger problem however is that there might be several potential fixes to any single issue highlighted by the linter, so choosing just one is quite a task... 🙂 Definitely would be an interesting extension project to create though, that is, read in clj-kondo's linting metadata and provide automatic refactoring actions based on those.

alidcastano19:04:13

Is the cond->> expression meant to be supported? I tried doing something like this, but assoc gives an lint error:

(cond->> initial-map
  (some? x) (assoc :foo bar))

borkdude19:04:58

@alidcastano

$ clj -e "(cond->> {} (some? 1) (assoc :foo 1))"
Execution error (ClassCastException) at user/eval137 (REPL:1).
clojure.lang.Keyword cannot be cast to clojure.lang.Associative
$ clj-kondo --lint - <<< "(cond->> {} (some? 1) (assoc :foo 1))"
<stdin>:1:30: error: Expected: associative collection or nil, received: keyword.
linting took 10ms, errors: 1, warnings: 0
That seems to be accurate?

alidcastano20:04:49

ah interesting, trying it in repl this works:

(cond-> {:x "foo"} 
  true (assoc :y "bar"))
result: {:x "foo", :y "bar"} this doesn’t:
(cond->> {:x "foo"} 
  true (assoc :y "bar"))
error: class clojure.lang.Keyword cannot be cast to class clojure.lang.Associative so i guess it’s not a bug in clj-kondo since clojure throws an error too (thanks for checking it, btw). but unless i’m using cond->> incorrectly looks to be a bug in clojure

borkdude20:04:32

@alidcastano It's not a bug in Clojure:

user=> (require '[clojure.walk :refer [macroexpand-all]])
nil
user=> (macroexpand-all '(cond->> {:x "foo"} true (assoc :y "bar")))
(let* [G__143 {:x "foo"}] (if true (assoc :y "bar" G__143) G__143))

alidcastano20:04:20

so cond-> evaluates it to (assoc G__143 :y "bar") but cond->> evaluates it to (assoc :y "bar" G__143) 😅

seancorfield20:04:47

cond->> is thread last so it threads your expression into the last position in the assoc call: (assoc :y "bar" data) which is incorrect usage.

alidcastano21:04:08

thanks for further clarifying, i do see now that official Clojure docs state that ->> is the thread last macro. I was reading the cond->> docs in http://clojuredocs.org and incorrectly inferred this was the only difference: threading does not short after the first expression