exactly, clojure-lsp in Cursive

interesting. are you sure the warning in your case is coming from clj-kondo?

and not from cursive for example

https://www.dropbox.com/s/bgu9eglc8vezvnz/Screenshot%202021-08-25%20at%2015.30.53.png?dl=0 - it seems coming from LSP server

Very interesting. Could you make a zip of .clj-kondo/.cache and send it to me, if it doesn't contain any sensitive info? @UKFSJSM38 and me are trying to solve this issue for some time now

The workaround is to remove .clj-kondo/.cache and .lsp/sqlite.db and then restart your workspace, but we would love to have some data to debug

Is that the same issue of cache removals? The User seems to be a schema from the project itself, not external deps

anyway, a zip would help confirm it indeed 🙂

yes, it would help if the screenshot also showed where User is coming from

more details = more better...

btw, it's interesting you're using Cursive. I think it would be useful to have some docs around how to use clojure-lsp in cursive

Yeah, actually I didn't know both would work fine together :thinking_face:

I will send the zip later today. Do y have Keybase or what do you prefer? The schema is defined in another ns and required with :refer :all

But how goes kondo cache help? I've run kondo from CLI and that was just fine, I assume it used the cache. Since the problem only appears in kondo via lsp, you perhaps need (also).lsp (or, in the case of IntelliJ, there is also lsp (without dot))

.lsp/sqlite.db is the folder used by clojure-lsp just for caching external analysis, when we remove it, clojure-lsp re scan the whole classpath again using clj-kondo (which should cache that on .clj-kondo/.cache as well)

@U0522TWDA the command line version only uses the cache created by the editor if both clj-kondo versions are exactly the same

good point, probably your clj-kondo cli version is different from the one used by clojure-lsp

No, both versions are the same

you can check is to see if there is only one recent .clj-kondo/.cache/* dir in there

and not two different ones, I mean inside the .cache dir

Sorry 😢 I have restarted LSP from Cursive and it does not show the error anymore.

Good news! I deleted kondo cache and restarted LSP and re-opened the file and see the error again

interestingly, I do NOT have .clj-kondo/.cache/ in the project dir now

the only relevant thing I seem to have is ./lsp/

restart cursive itself perhaps

huh

now I'm really confused ;)

hum, even if your classpath is cached on .lsp/sqlite.db , clojure-lsp calls clj-kondo to lint the project paths at every startup, then it should create a .clj-kondo/.cache (only if you have a .clj-kondo folder)

Me too. Now the problem is there even in CLI:

❯ java -jar ~/Downloads/clj-kondo-2021.08.06-standalone.jar --lint src/mine/core.clj
src/mine/core.clj:4:35: warning: use alias or :refer
src/mine/core.clj:38:12: error: Unresolved symbol: User

what makes sense because there is no cache, right @U04V15CAJ?

@U0522TWDA Please provide more details. The complete source.

it looks like you're using :refer :all or something (from the linter warning I can see that)

and that's expected not work with without a cache

Correct, the .clj-kondo/ dir that I deleted recently has not been recreated by running the CLI. @U04V15CAJ I'd love to but it is company property so I cannot really share more than snippets 😿

Yes, I am using refer all, I think I mentioned it above

you need to make LSP re-index your project

@U0522TWDA probably you will be able to repro if create a new sample project with schema.core dep?

don't know how to do that in Cursive

(ns
  (:require [company.schemas :refer :all] ; User lives here
            [schema.core :as s]))
(s/defn backoffice-user?
  [user :- User]
  ...)

> you need to make LSP re-index your project for clojure-lsp, removing .lsp/sqlite.db or changing anything in your project.clj/deps.edn should work

ok, will try to make a repro repo later today. Thank you for all the support!

Ok, so if I have (:require [kondo-lsp-cursive-schema-problem.core :refer [User]]) then kondo is happy but if I change it to ...:refer :all then it says "Unresolved symbol: User" @U04V15CAJ do you want a .tbz of the whole project repo or is this a known problem?

a public repo on Github would be the best, otherwise a zip/tar.gz is enough as well

@U0522TWDA That example is expected to work like that, if you don't have a .clj-kondo/.cache with the namespace kondo-lsp-cursive-schema-problem.core linted

but if you do have .clj-kondo/.cache dir and then you lint that namespace, after that, it should work

Ah, I expected that if I open a new project, LSP would index it automatically. Obviously it did not

so lint the other namespac

yes, I would expect that too, but I'm not sure why it doesn't

How do I get LSP to index anything? I changed a comment in project.clj but still not .clj-kondo ...

you must create the .clj-kondo dir yourself

only remove the .cache dir from it, not the dir itself

you're expected to host some configuration in that directory

.clj-kondo/config.edn

and when you have a .clj-kondo dir, only then will clj-kondo store cache info there

I wonder if clojure-lsp should always create the .clj-kondo dir in the project. what do you think @U04V15CAJ?

yes, I'm fine with that

otherwise projects without that folder always will have that issue

just at the same position as .lsp

perhaps also put a config.edn there automatically with just an empty map

if it doesn't exist

https://github.com/holyjak/tmp-kondo-lsp-cursive-schema-problem

> perhaps also put a `config.edn` there automatically with just an empty map I suppose people would think that .clj-kondo/config.edn should not be commited if we do that automatically 😕

@U0522TWDA I'll try to repro with clojure-lsp later today, thanks

Added the config there , cache created, problem persists. Both ns are indexed: kondo-lsp-cursive-schema-problem.core.transit.json kondo-lsp-cursive-schema-problem.schemas.transit.json

@U0522TWDA I don't think this repro makes sense. You are referring the same namespace with :refer :all from the namespace itself

(ns kondo-lsp-cursive-schema-problem.core
  (:require
    ;[kondo-lsp-cursive-schema-problem.core :refer [User]]
    [kondo-lsp-cursive-schema-problem.core :refer :all]
    [schema.core :as s]))

> I suppose people would think that `.clj-kondo/config.edn` should not be commited if we do that automatically That is much less of a risk/inconvenience than the current state when linting does not work fully out of the box. (Of course we can blame the user - me - for not reading kondo docs and expecting stuff to just magically do what I want :))

OMG, sorry, typo

When I change it to [kondo-lsp-cursive-schema-problem.schemas :refer :all] then it works for me

Right, when I fix the require, it works at once

> That is much less of a risk/inconvenience than the current state when linting does not work fully out of the box. (Of course we can blame the user - me - for not reading kondo docs and expecting stuff to just magically do what I want :)) But not creating that would not cause the issue, it was just a suggestion, the issue here is the .clj-kondo folder creation

so, in the end the issue was the .clj-kondo folder that didn't exists, right?

I think so

I think creating the config.edn is a nice addition: it suggests where people should store their config

perhaps with links to the config page :)

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

In the repro, yes. At work it did/does exist. But when I open it, the cache has only files for very few namespaces, not including the .schemas one. Why could that be?

> I think creating the config.edn is a nice addition: it suggests where people should store their config we can do that I think, and re-think if anyone complains

> Why could that be? Probably removing both .lsp/sqlite.db and .clj-kondo/.cache would solve

No, sorry, missed it, .schemas as well as .core are there

perhaps the indexing broke off with an error?

anything on clojure-lsp server log? https://clojure-lsp.github.io/clojure-lsp/troubleshooting/#server-log

I do see this:

$ ls .clj-kondo/.cache/2021.08.07-SNAPSHOT/clj
kondo-lsp-cursive-schema-problem.core.transit.json    kondo-lsp-cursive-schema-problem.schemas.transit.json

well I would also expect some for clojure itself and schema

so it seems it didn't index deps

I think what happened was:

oh wait, I have 2 cache dirs:

$ ls .clj-kondo/.cache/2021.07.28/
clj  cljc cljs lock

so that's the one with all the deps

but this is using an older clj-kondo it seems

` $ clojure-lsp --version clojure-lsp 2021.07.28-14.24.06 clj-kondo 2021.07.28

ah, that makes sense

the .schemas transit file does contain the User (thanks, jet !)

there was no .clj-kondo dir, clojure-lsp called clj-kondo that linted classpath and lsp saved .lsp/sqlite.db , but nothing saved on .clj-kondo/.cache as the did was not there. After creating the .clj-kondo folder we need to re-scan the classpath to fulfill the clj-kondo cache folder, that's why removing .lsp/sqlite.db should fixes it, WDYT?

yeah. always ensuring a .clj-kondo dir would fix that problem as well

exactly

maybe that would solve a lot of headache

I can see one edge case with this

what if people have a mono-repo and only one .clj-kondo dir at the top level

and a shared config for all projects inside the mono repo

I don't know if this happens a lot

not sure where the sqlite is in Cursive+LSP, I have no .lsp, only lsp/ that contains log/ and conf/clojure.json

that lsp folder is created by the IntelliJ LSP plugin

yeah, ATM it's suggested that you use clojure-lsp at the mono root, not sure if clj-kondo caches would conflict from subproject to subproject though

The .lsp folder is created by clojure-lsp though. Perhaps it should be called .clojure-lsp? ;)

ok, let's ignore the mono-repo situation for now, I'm not using that myself in that way, perhaps an edge case to consider later

> The .lsp folder is created by clojure-lsp though. Perhaps it should be called .clojure-lsp? 😉 Yeah, there is a issue about that, we would need avoid the breaking changes, but it'd be the ideal indeed

Any idea why I do not have that repo created? Is it because the IntelliJ LSP plugin runs clojure-lsp in some other dir or something?

perhaps the lsp/logs tells something about whether / how its doing stuff?

FYI: https://github.com/clojure-lsp/clojure-lsp/issues/528

@U0522TWDA follow the https://clojure-lsp.github.io/clojure-lsp/troubleshooting/section, the server logs should help

both lsp/log/clojure_out_20210825.log and _err_ are empty though

I don't think both logs are related with clojure-lsp:https://clojure-lsp.github.io/clojure-lsp/troubleshooting/#server-log

according to https://github.com/gtache/intellij-lsp#faq those files have, I assume, stdout and stderr from clojure-lsp. I will study clojure-lsp docs to figure out where its actual logs are.

I think the _err_ is the stderr from the clojure-lsp process, which unless a huge bug prints to that

what we want is the custom log from the server, which the plugin (since it's a generic intellij LSP plugin) doesn't know about it, unless the plugin explicitly integrates with, which is what Calva does

hm, the newest log I found was <.tmpdir>/clojure-lsp.11604520859388497386.out which is from yesterday and has last log from 2021-08-24T13:01:27.545Z

you can easily add {:log-path "/tmp/clojure-lsp.out"} in your .lsp/sqlite.db , this will help get the log from the sample place

Will do. I have killed the processes and a new clj-kondo-lsp-server-standalone.jar was started but no new logfile

Hm, I've created

❯ cat .lsp/config.edn                                                                                                  
{ :log-path "/tmp/clojure-lsp-myapi.out"}

Can you use a different folder than tmp? (that's why it's not the default to use tmp, but java tmp folder, for persmisions issues, specially on macos)

I have done that now and restarted, still no log

Interesting, According to Activity Monitor's Open Files, it does not have any log file open. Also, its CWD is wrong (I have 4 projects open in IntelliJ and it is one of them but not the one which I am actively using now)

are you really using clojure-lsp? Can you check if there is a clojure-lsp process running?

No, it is not, only clj-kondo-lsp-server-standalone.jar Does it not include clojure-lsp?

I followed these instructions https://github.com/clj-kondo/clj-kondo/blob/master/doc/editor-integration.md#lsp-server-1

oh, you are using the clj-kondo LSP project, not clojure-lsp 😅

You are using https://github.com/clj-kondo/clj-kondo.lsp, not https://clojure-lsp.github.io/clojure-lsp/

I am sorry, I am new to all this and do not distinguish properly between what is what 🤯

they both are LSP servers for clojure and both use clj-kondo, but they do things different

even so, it seems that the clj-kondo.lsp has the cache issue as well @U04V15CAJ 😂

I see now. Which one of the two should I use? I picked the one b/c that is what clj-kondo pointed me to...

I think clojure-lsp is the closest to Cursive, I'd suggest giving it a try https://clojure-lsp.github.io/clojure-lsp/installation/

Aaaaah :)

Yeah, clj-kondo lsp is not clojure-lsp :)

I can see how that is confusing :)

the clj-kondo lsp doesn't index your project at all

you still have to do it manually, clj-kondo is very lazy

but clojure-lsp is pro-active 💪

Ok, thx! Then I will switch to clojure-lsp and see how that works. Still, I do not understand why it fails to resolve User in my case because I see the transit file for the schemas ns, which I would believe means that kondo has indexed it. Or?

It indexes it if you lint it manually on the command line in the presence of a .clj-kondo directory, or if you edit the file in your editor and it gets linted then (also in the presence of a .clj-kondo dir)

And then it should indeed work. Your repro did work for me.

Ah, somehow it works here now as well. I guess it was some timing issue, with kondo's updated info not being propagated all the way via LSP to Cursive.

I think I figured out what is going on. Not sure if it is exactly a bug, but seems like it should be. Posting code in a moment

yes, that's what I mean, I think self-references should not count as usages for the unused private var linter

Given that using one arity of a multi-arity function as an implementation of another is as fairly common pattern, perhaps clj-kondo should ignore the internal usages within the definition of the function?

I will add an issue.

seems like this should apply for all functions, not just private ones, no?

nvm, I suppose you don’t get the warning for public functions. 🐶

well, clojure-lsp does that but perhaps @UKFSJSM38 already took that into account

yeah, that's something to improve/fix on both unused-private-var and clojure-lsp/unused-public-var linters IMO, they consider the function internal usage

ok, I'll first improve the private one and perhaps the same logic can be applied to the public one. perhaps by adding a :self-ref true or so on the usage

Looks good!

LSP code lens are affected by that as well

I just wonder if we should just fix the lint, but references and code lenses should still show those usages

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

Fixed on master.

Probably {:lint-as {... clj-kondo.lint-as/def-catch-all}} works here

Yep! It works! Thanks @U04V15CAJ ❤️