Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-08-24

Channels

#clj-kondo
<
2023-08-24
>
pithyless10:08:15

Unexpected error. Please report an issue.
java.lang.IllegalArgumentException: no conversion to symbol
Is there a way I can get more info on where clj-kondo failed during parsing (to help produce a minimal repro)?

borkdude10:08:31

Try CLJ_KONDO_DEV=true ...

pithyless10:08:55

I found https://github.com/clj-kondo/clj-kondo/issues/1670 But I don't think it's the same, since I'm testing with 2023.07.13

borkdude10:08:11

Perhaps this is a configuration issue

pithyless10:08:19

config had: 

:unresolved-symbol {:exclude [(symbol.without.slash [symbols ...])]}

borkdude10:08:41

feel free to post an issue so clj-kondo can handle this better

pithyless10:08:02

Thanks @U04V15CAJ for quickly pointing me to the probable cause!

Stig Brautaset10:08:18

❓ Our coding guidelines allows calling private functions (with #') from tests, but disallow it otherwise. Our solution so far has been to run clj-kondo twice: one for “src”, and again for test: clj-kondo --config '{:linters {:private-call {:level :off}}}' --lint test . I’m wondering if there’s any appetite for a config option (and whether it’s even possible) to make the :private-call linter take a path ignore files?

Stig Brautaset10:08:59

I’m thinking something like {:linters {:private-call {:ignore-paths ["test"]}} in config.

Stig Brautaset10:08:06

I’m also open to being told it’s a terrible idea 🙂

borkdude10:08:10

This is what the :config-in-ns option is for, no need to implement this for each linter specifically

borkdude10:08:55

the private-call linter won't report #'foo calls anyway btw

Stig Brautaset10:08:58

That is contrary to my experience, where the private-call linter does report for #'foo. I just tried it again. However, :ns-groups and :config-in-ns looks like they have my back — if I can only get the syntax right 🙂

borkdude10:08:32

$ clj-kondo --lint - <<< "(ns foo) (defn- foo []) foo (ns dude (:require [foo])) (#'foo/foo)"
linting took 12ms, errors: 0, warnings: 0

borkdude10:08:42

vs. 

$ clj-kondo --lint - <<< "(ns foo) (defn- foo []) foo (ns dude (:require [foo])) (foo/foo)"
<stdin>:1:56: error: #'foo/foo is private

Stig Brautaset10:08:27

How curious! I can reproduce that, but that is not the behaviour I’m seeing in our projects.

borkdude10:08:00

counter-repro welcome

Stig Brautaset10:08:03

me experiments more

Stig Brautaset11:08:51

Aha, I think I have been tricked by the error clj-kondo prints. This is error: #'foo/now is private — but the actual code is: 

(bond/with-stub! [[foo/now (constantly #inst "2017-03-30T20:52:03.690-00:00")]
(`bond` is a stubbing library.)

Stig Brautaset11:08:47

Nevertheless, ns-groups and config-in-ns seems like it should work for me here.

borkdude11:08:19

if bond/with-stub! is supported via a hook, you can maybe update the hook to suppress the private-call warning

Stig Brautaset11:08:30

I’m not sure what “supported via a hook” means, I’m afraid, though that sounds interesting. The source is here: https://github.com/circleci/bond/blob/main/src/bond/james.clj#L96-L105

Stig Brautaset11:08:54

… though I’ve now managed to get the :config-in-ns option to work, which is a massive improvement on what we have

borkdude11:08:10

> I’m afraid, though that sounds interesting Fear not :) What I mean is, did you do anything to configure this macro to not cause any lint warnings?

borkdude11:08:39

You can also configure it like: 

{:config-in-call {foo.bar/bond {:linters {:private-call {:level :off}}}}}

Stig Brautaset11:08:59

Mmm! That’s perhaps even better here. Nice and narrow.

Stig Brautaset11:08:12

Thank you!

👍 2