I think we should re-open the issue on clj-kondo, still makes sense to me so we can support that on LSP side, WDYT @U04V15CAJ?

reopend!

@U02H56JNDK2 Can you give the full context (code) of how you are importing + using your var and in which clojure dialect?

@U04V15CAJ will do later in the evening when I'm at the computer. What do you mean by dialect? I'm using "pure" Clojure 1.11.1

OK, I meant CLJS or CLJ or ...

Clj it is 👍

I closed the issue again, with a comment. If we reach another conclusion I can re-open it, but I think it's the job of who uses the analysis to "do the right thing" here

I think alternatively you could require the namespace and write ->SomeRecord instead. Which is more idiomatic than going through the Java constructor too probably

I am using brute (https://github.com/markmandel/brute/) in my project, an ECS implementation. Without going too much into details, it uses the class name as index in its internal storage. For fetching data it’s common to have code like (brute.entity/get-component system entity Rectangle) where Rectangle is the imported class, created from a defrecord.

So I have to import the class in order to use brute. But I understand that this is a corner case and it doesn’t bother me too much. So I’m fine with the issue being closed. Eventually I might just rename the namespace.

It can be supported but my opinion is that this has to be inferred based on the java-class-usages + combination of existence of clojure namespaces

So imo it's more a "consumer of the analysis" (being lsp here) problem than "the analysis is incorrect" problem