clj-kondo 2024-05-14 | Slack Archive

didibus03:05:46

My macro can be used inside itself. I'm writing a hook for it. And I already implemented an inner walk so that when the outer macro is linter is expands the inner ones as well. But my only remaining issue is if the inner macro calls are aliased, I don't know how to equal them? Currently I do (api/sexpr token) and check if it's equal to the qualified and unqualified. But my guess is that returns alias/name and not the expanded form. What should I do?

borkdude09:05:57

You can use api/resolve-symbol to resolve the alias

borkdude09:05:43

I don't think you have to let the hook do the work of expanding the inner calls. Why not let clj-kondo do that for you if you just expand like you would in a normal macro

didibus19:05:25

Maybe I did something wrong. But my macro also needs to expands the inner macros. I think it's because I need to expand the inside ones first.

👍 1

didibus04:05:53

Another issue I have is I get: unresolved symbol defn! for some reason. My hook does convert it to a defn, but I would not expect clj-kondo to think the symbol is gone? Or am I supposed to also return a declare defn! or something to teach it? This only happens when using :refer :all

didibus04:05:17

Hum, I ran: > $ clj-kondo --lint "$(clojure -Spath)" --copy-configs --skip-lint > $ clj-kondo --lint $(clojure -Spath) --dependencies --parallel Explicitly (instead of relying on clojure-lsp) and the unresilved symbol defn! disappeared.

borkdude09:05:05

not sure

Alexander Kouznetsov23:05:11

Looks like the stale clj-kondo cache issue.

Derek17:05:15

Has anyone considered a lint warning for the following form:

(str "string literal")

If not, is there interest?

➕ 3

borkdude17:05:38

I guess we could but it seems a bit like a degenerate case?

Derek17:05:05

Just came across it (copied and pasted) multiple times in a project file

Derek17:05:11

It's not a big concern

borkdude17:05:29

I'll keep it in mind

👍 1

Stig Brautaset17:05:25

Heh! I just came across something similar in a PR: (str (format fmt-str arg1 arg2))

😆 1

tomd06:05:29

I've come across it quite a few times over the years. Had been on my list to raise for a while. Seems somewhat consistent with the fact kondo lints :single-logical-operand , :single-operand-comparison and :redundant-call imo. It could even be added to the latter, no?

👍 2

borkdude07:05:29

yeah makes sense. issue welcome.

borkdude10:05:57

ok, I pushed a POC to the branch redundant-call-string:

$ clj -M:clj-kondo/dev --lint - --config '{:linters {:redundant-call {:level :warning}}}' <<< '(str "foo") (str (format "hello"))'
<stdin>:1:6: warning: Argument to str is already a string
<stdin>:1:18: warning: Argument to str is already a string
linting took 38ms, errors: 0, warnings: 2

borkdude10:05:33

https://github.com/clj-kondo/clj-kondo/issues/2323

tomd11:05:58

Looks good. One bit of feedback: "Argument to str is already a string" is maybe a bit subtle, because multiple args are often already strings. It's the fact that a single string is provided that is a lint warning. Maybe "Single argument to str is already a string" is a bit clearer?

👍 1

tomd11:05:21

(sorry didn't put that on the issue as it's not currently linked to the branch)

👍 1

borkdude11:05:25

yeah this is pretty much a hack in the type system right now, the proper thing to do would be to report a redundant call at the location of the str call

👍 2

borkdude11:05:16

Better now:

$ clj -M:clj-kondo/dev --lint - --config '{:linters {:redundant-call {:level :warning}}}' <<< '(str "foo") (str (format "hello"))'
<stdin>:1:1: warning: Single argument to str already is a string
<stdin>:1:13: warning: Single argument to str already is a string
linting took 39ms, errors: 0, warnings: 2

borkdude14:05:48

borkdude14:05:00

now on master

❤️ 3

Derek15:05:13

Thanks @U04V15CAJ

borkdude16:05:00

darn, a false positive with ;)

(are [x y] (= x (str y))
  "foo" "bar"
  "foo" 1)

✅ 1

💥 1

2024-05-14

Channels