How does this question relate to clj-kondo and can you give a code snippet / repro to explain what you're talking about?

Do you mean this?

$ clj-kondo --lint - <<< '(defn foo [^double x] x) (foo 1)'
<stdin>:1:31: error: Expected: double, received: positive integer.

Exactly

That's a kondo related question, no?

yes, but it wasn't clear to me when you first posted your message

yes, I think this should be fixed

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

Thanks!

I see

thanks

if clojure -Spath could be made aware of nbb's builtin deps that would be ultimate smoothness

agreed

we've done this for babashka, it may happen at some point for nbb too

oh

lsp recognizes bb.edn and then it inserts some configs for built-in deps for bb

maybe this could also be configured via .clojure say deps resolvers functions

?

well whatever. I was just wondering if it could be in user space.

you can do it in user space via lsp config

but it requires some configuration

you can tell lsp what classpath to use for analysis and you can use a bb or nbb script for this

I tried adding

:deps {funcool/promesa {:mvn/version "10.0.571"}}

clojure -Spath 
src:/home/benj/.m2/repository/org/clojure/clojure/1.11.1/clojure-1.11.1.jar:/home/benj/.m2/repository/org/clojure/core.specs.alpha/0.2.62/core.specs.alpha-0.2.62.jar:/home/benj/.m2/repository/org/clojure/spec.alpha/0.3.218/spec.alpha-0.3.218.jar

I thought I can copy the exported config now 😛

what I mean with bb.edn is: just put it there and then restart clojure-lsp

clojure -Spath doesn't look at bb.edn

ah

ah yea it pulled those because I added an empty deps.edn and forgot it

ah so only lsp does some magic, not the level of kondo?

I guess I need to pass --copy-configs

with kondo only, use the second option I posted in first reply

more details here: https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#exporting-and-importing-configuration

ahh 👍

Here, using the with-bound hook from the example doc, we can see that the w in what highlights the entire form. This is because the name-row/end-row goes from 4-6 and name-col/end-col is 1-7. If we ask what is under the cursor, we see it's picking up the let

There has been a change where things from hook that don't have locations get a :derived-location so you can still see where it's from more or less. It could be that clojure-lsp doesn't always take this into account. cc @UKFSJSM38

The derived-name-location isn't right though, a name can't span rows

the reason here is that the location is derived from the surrounding form that does have a location. derived locations aren't accurate and can be ignored if they lead to issues

I'll be afk now, but if you have more to share on this or want to do a deeper diagnosis: I will release a new version of clj-kondo tomorrow so the more time you can save me by doing some pre-work on this, the better

💤

@U0BUV7XSA this probably points that your hook should have a with-meta otherwise that will happen

https://github.com/nubank/state-flow/blob/master/resources/clj-kondo.exports/nubank/state-flow/nubank/state_flow.clj#L34

I think there's two issues: 1. The name-* metadata when derived-name-location is true should derive from the name, not from the form. 2. There's no way afaik, for a hook to say that a derived token should be included in analysis output or not, also the derived-name-location flag is insufficient for lsp to know which should be ignored or kept. a. Some macros can combine names like (defendpoint a "b" ...) => (defn a_b ...) a_b should be derived otherwise really nasty metadata calculation has to be done by hook authors. b. In the example above, the let probably shouldn't leak into analysis at all, since it's not actually present in the form, nor should it be considered a var-usage of clojure.core/let

@UKFSJSM38 but there's no valid position for that let in the example.

@UKFSJSM38 I think that before derive-* was introduced the locations would be nil maybe in lsp we could change them back to nil as that would at least cause far fewer issues than what I'm now seeing with library hooks that do not specify meta

TBH not sure, that was a headache on Nubank's state-flow and derived-name-location kind of fixed that regression, I think we added tests for that but would need to do carefully

Your macro is pretty similar to nubank/state-flow defflow macro regarding the let, maybe you could try adding the with-meta and check if still have the issue

That's just the macro in the kondo docs. The macros at metabase are much more complicated and I did start adding meta but it's starting to hit a wall because of 2b above.

so you are suggesting to make name locations nil when they are derived instead of ignoring totally those analysis?

I think 1. kondo should fix derived names to be based on name not form as they are giving impossible dimensions for names. 2. kondo introduces an api/internal-node function or something that would hide (or mark) nodes that are not reflected in the code from being output to analysis. Until then, lsp should probably make name locations nil when derived.

We'd have to see what that does to rename though

I like 1, let's see what borkdude think about that, meanwhile we could test it namking name locations nil, I'd like to do that carefully if possible (not include on tomorrow's release)

Here's a macro that is registering a usage of my dosomething fn, then what happens if I rename it.

yeah, pretty undesired behavior

And I don't think there's a meta position i can apply that wouldn't mess things up

yeah, me too, we could ignore specific analysis on rename, but sounds like a weird workaround... probably ignoring or fixing it on kondo side or lsp parsing kondo analysis is the best

If you have a proposal, let me know

the approach with derived locations is "something is better than nothing". e.g. if you have a lint warning about the name, but there is no location, it will appear at the location of the surrounding form

if there is no location to point to, the lint warning would not appear anywhere