For example, this definition https://github.com/fulcrologic/fulcro-rad-semantic-ui/blob/c22ab504d6030e1174a3166e1f1e6f5f5f597f11/src/main/com/fulcrologic/rad/rendering/semantic_ui/autocomplete.cljc#L31-L41 produces the following analysis data:

{:fixed-arities #{1}
       :end-row nil
       :name-end-col 31
       :name-end-row 31
       :name-row 31
       :ns com.fulcrologic.rad.rendering.semantic-ui.autocomplete
       :name normalize-options
       :defined-by clojure.core/defn
       :lang :clj
       :filename "... /resources/repos/fulcrologic/fulcro-rad-semantic-ui/src/main/com/fulcrologic/rad/rendering/semantic_ui/autocomplete.cljc"
       :col nil
       :name-col 14
       :end-col nil
       :row nil}

might be a bug

@U04V15CAJ I thought so, but wanted to check with you first just in case. Doesn't look like a result you would expect for such a definition?

Notice that other location fields do contain a value.

As I said, might be a bug

Feel free to post an issue, not sure why it happens. I or you or someone else needs to take a look

Alrighty, thank you. I'll have a shot at a fix.

@U04V15CAJ I have a fix but I don't know how to write a test for it and I don't fully understand why the code is written the way it is, probably because I haven't studied how rewrite-clj works. The problem is https://github.com/clj-kondo/clj-kondo/blob/787a8f75df65d82794c1cc8407d88a7b93a4c298/src/clj_kondo/impl/namespace.clj#L100-L104. reg-var! expects to find the missing location fields to be in the (meta expr), but it's in the passed in metadata for this definition and others like it which fail. Replacing the let binding with:

expr-row (or (:row m) (:row metadata))

I see. I'm not sure why we don't always use "metadata", this is a bit messy

I'm fine with adding or there, if that works

Seems to. I'll do a bit more manual testing, but not sure how to unit test such a case because the var definition I'm testing against is a custom macro.

with a hook or so?

Sorry, I don't yet understand how to do that. There is already a hook for defmutation that Fulcro https://github.com/fulcrologic/fulcro/blob/6b53c03787344db00cd7f4b92f779e861cc2fcb3/src/clj-kondo/clj-kondo.exports/com.fulcrologic/fulcro/com/fulcrologic/fulcro/clj_kondo_hooks.clj#L4. Is there some way I can leverage that within the tests? I don't mean to bother you with this. If you would prefer I can just open a ticket or PR with the findings and solution so far.

I was just asking, how the custom macro was handled in clj-kondo

you can take a look at the hook tests how to do this

It could also be a sign that the hook doesn't properly attach the location metadata

Good point. Reading through the hooks workshop made me wonder why the meta doesn't include the location information anyhow.

That does look to be the case here. The location meta is on the incoming node but not the return value. Maybe all the (or (:name-col metadata) (:col metadata)) -like code in reg-var! is there just in case of situations like this?

Perhaps ... it's a while ago since I touched that

But I think a location is always better than none :)

A wrong location could be worse than none :man-shrugging: As for the tests, I'm looking at clj-kondo.hooks-test, but it's not so clear to me. I'm to define a simplified hook similar to Fulcro's defmutation and put it either in a string right in the test, or in corpus/hooks, and then use it in a call to lint! to assert against?

BTW, there are quite a few libraries out there that produce such analysis results. Maybe there should be a warning or something somewhere?

there might also be tests in analysis_test regarding hooks, I'm not sure

There is one https://github.com/sheluchin/clj-kondo/blob/787a8f75df65d82794c1cc8407d88a7b93a4c298/test/clj_kondo/analysis_test.clj#L938-L956

ah good, well, similar to that one then ;)

you could also put the code in a directory in corpus if you prefer that

https://github.com/clj-kondo/clj-kondo/issues/1812 There's an issue for it. I think I have a fix PR as well. Thank you for the guidance, @U04V15CAJ 🙏

Merged, and thank you!

Unused public var is not a clj-kondo feature but a #lsp feature. Can you post your question there? I'm not sure how that config works. Or maybe @UKFSJSM38 can reply here 🧵

Oh, I was just reading this example here (which references .clj-kondo/config.edn), so I just assumed 😬 https://clojure-lsp.io/settings/#clojure-lspunused-public-var

thanks anyway

yeah, it's a custom linting rule

it's fine to ask the question here as well, but you might get better replies in #lsp

Out of curiosity @USW6URK47, what or where calls that handler funcion?

an AWS lambda (Node.js)

it is built with Shadow-cljs:

...
:builds {:lambda {:target  :node-library
                  :exports {:handler my-ns/handler}
...

I see, so it comes from shadow, I'm wondering if we could get analytis from shadow edn as well @U04V15CAJ in the future along with bb.edn

Wasn't the original question why the config didn't work?

I mean, if we have analysis on shadow-cljs.edn , then we would know that function is being called there, so users wouldn't need to specify which function they want to exclude from linter

sure, but excluding should work no matter what

ah yes, excluding via code and config should work indeed, @USW6URK47 just add the linter config on .clj-kondo/config.edn as mentioned https://clojure-lsp.io/settings/#clojure-lspunused-public-var

@UKFSJSM38 He already did that. That was the original issue: that this didn't work for him. See original post.

Got it, sorry, I misread the question. @USW6URK47 Hum, it does seems to work for me with:

(my-ns)

(defn foo [])

{:linters {:clojure-lsp/unused-public-var {:exclude #{my-ns/foo}}}} 

{:linters {:clojure-lsp/unused-public-var {:exclude #{my-ns}}}} 

Make sure to re-edit de buffer after changing a config to re-lint the file

(BTW, that sounds like a good nice to have, clojure-lsp could re-lint the project when user changes a config.edn: https://github.com/clojure-lsp/clojure-lsp/issues/1247)

I found my issue... though I don't understand why it would have any effect at all 😮 I had something commented out like so:

{:linters {:clojure-lsp/unused-public-var {:exclude #{my-ns/foo}
                                           #_#_:exclude-regex #{"my-ns\..*-test"}}}}

When I remove #_#_:exclude-regex #{"my-ns\..*-test"} it works. Thanks for your patience, both

:thinking_face: I figured it out... I was tricked by the (single) back-slash

About https://github.com/clojure-lsp/clojure-lsp/issues/1247, this was done on master :) Every time user save a clj-kondo or lsp config, we re-lint all opened files so the UX is smoother