Clojurians Log v2

Currently not but we could make it so

Issue welcome

It might be possible to use the file name pattern for this

https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#namespace-groups

but I doubt it

yeah, perhaps using config-in-ns + filename pattern

I created an issue https://github.com/clj-kondo/clj-kondo/issues/2521

for a mostly cljc codebase that wouldn't work, since most of the clj code is in cljc files, but clj-kondo can already tell what's clj code and what's cljs so I think you are right that it is not supported yet

good point

yeah the :langs option should be nice to have

I think it is ok to have a record specify multiple protocol/interfaces?

(defprotocol IFoo
  (foo [_])
  (bar [_]))

(defprotocol ITwo
  (blarg [_]))

(defrecord Foo []
  IFoo ITwo
  (foo [_] (println "foo"))
  (bar [_] (println "bar"))
  (blarg [_] (println "blarg")))

(def r (Foo.))

(foo r)
(bar r)
(blarg r)

$ clj-kondo --lint myrepro.clj 

myrepro.clj:9:3: warning: Missing protocol method(s): foo, bar

ehhh is it ok to mix methods like that? I never knew. the missing-protocol-method assumes you will specify the method that belongs to the protocol mentioned before it

if this is allowed, I might just delete this whole linter

well maybe not it's ok ish

I think it's fixable now that I thought about it some more

just throw all the methods together and compare the methods provided, should work

The issue was raised for me on cljdoc while trying out the new version of clj-kondo: https://github.com/cljdoc/cljdoc/blob/2c784bd01653d9a65aa0a50cd980cc608d728513/src/cljdoc/s3.clj#L13-L74

Just move the AutoCloseable before the last method

I guess you probably won't be checking Autocloseable interface.

would be a better fix imo

true, interfaces not yet (but could be supported in the future, one step at a time)

Ah. Lemme try that.

I agree that clj-kondo should support this, but I'd say only if ClojureScript also supports it

which I'm gonna try now...

cljs.user=> (defprotocol IDude (foo [_])) (defprotocol IDude2 (foo2 [_]))
false
false
cljs.user=> (defrecord MyDude [] IDude IDude2 (foo [_]) (foo2 [_]))
WARNING: Bad method signature in protocol implementation, IDude2 does not declare method called foo at line 1 <cljs repl>
cljs.user/MyDude

Cool, I might have just been using something that happens to work.... but is not kosher... dunno.

Each spec consists of a protocol or interface name followed by zero
or more method bodies

I'd say that is how clj-kondo expects it too

but interesting find nonetheless

Yeah. Docstring is pretty clear there. I might have got lost in the weeds with plural mentions of interfaces and protocols later in docstring body. So in summary: clj-kondo once again helped me tidy up my code!

😅

Thanks for your help in diagnosing!

and thanks for teaching me about yet another clojure JVM edge case!

Here's the code: https://github.com/clj-commons/clj-yaml/blob/595e2961fc9378dcfa6de2a97e522b5839e33523/src/clojure/clj_yaml/core.clj#L177-L249 Here's the findings:

src/clojure/clj_yaml/core.clj:186:18: warning: Missing protocol method(s): encode
src/clojure/clj_yaml/core.clj:186:18: warning: Missing protocol method(s): decode

the warnings seems legit but the impl seems legit too since the yaml parser probably never produces those clojure types

thus you don't have to ever encode them

to get rid of the warning you could add a no-op method that just throws when executed

Yeah. If those methods were called, it would indicate an internal error, I think. The code will already throw for those missing methods if called. I suppose it would be a form of documentation to add missing methods that throw.

yeah or you could just clj-kondo/ignore the thing

I think I'd add the no-op methods

The default throw is pretty good:

(decode :keyword {})
  ;; => Execution error (IllegalArgumentException) at clj-yaml.core/eval12017$fn$G (core.clj:177).
  ;;    No implementation of method: :decode of protocol: #'clj-yaml.core/YAMLCodec found for class: clojure.lang.Keyword

yeah, just for making things clear(er)

50/50 on it

Same. I guess any change introduces risk, I'll tell clj-kondo to ignore the linter for this code block and add a comment.

BTW, are there still known issues with redundant ignore findings? I ask because when I added the inline ignore, it works, but I now see a redundant ignore finding on my inline ignore.

yes, it was just filed as an issue with clj-kondo, see github issues 😅

Oh, I see it, thanks: https://github.com/clj-kondo/clj-kondo/issues/2524