Clojurians Log v2

Does clj-kondo do anything with :arglists metadata or does it use the underlying argument declarations? (this is in the context of Eastwood trying to check calls using :arglists which I recall having problems with in the past)

(and I guess the same Q applied to LSP @ericdallo? My quick experimentation suggests that both kondo and lsp rely on the actual argument declarations and ignore the :arglists metadata?)

clojure-lsp totally relies on clj-kondo https://github.com/clj-kondo/clj-kondo/blob/master/analysis/README.md, in this case :arglist-strs from https://github.com/clj-kondo/clj-kondo/blob/master/analysis/README.md#data. I'm not sure if clj-kondo fill it with that :arglists metadata

Thanks @ericdallo — as far as I can tell, clj-kondo ignores the :arglists metadata, based on limited experimentation. The downside is that “show hover” in Calva seems to come from LSP which therefore shows the actual argument lists rather than any doc-friendly :arglists that doc would show — but at least the linting is done correctly, which is my main concern.

I see, yes, you are right, I confirmed that show hover for ns clojure.core macro shows [name & references] instead of the arglists metadata '([name docstring? attr-map? references*])

this is the analysis data returned from clj-kondo for the ns macro:

{:end-row 5809,
  :name-end-col 13,
  :name-end-row 5753,
  :name-row 5753,
  :added "1.0",
  :ns clojure.core,
  :name ns,
  :defined-by clojure.core/defmacro,
  :filename
  "/home/greg/.emacs.d/.local/etc/workspace/.cache/clojure.core.clj",
  :macro true,
  :col 1,
  :name-col 11,
  :end-col 71,
  :arglist-strs ["[name & references]"],
  :varargs-min-arity 1,
  :doc
  "Sets *ns* to the namespace named by name (unevaluated), creating it\n  if needed.  references can be zero or more of: (:refer-clojure ...)\n  (:require ...) (:use ...) (:import ...) (:load ...) (:gen-class)\n  with the syntax of refer-clojure/require/use/import/load/gen-class\n  respectively, except the arguments are unevaluated and need not be\n  quoted. (:gen-class ...), when supplied, defaults to :name\n  corresponding to the ns name, :main true, :impl-ns same as ns, and\n  :init-impl-ns true. All options of gen-class are\n  supported. The :gen-class directive is ignored when not\n  compiling. If :gen-class is not supplied, when compiled only an\n  nsname__init.class will be generated. If :refer-clojure is not used, a\n  default (refer 'clojure.core) is used.  Use of ns is preferred to\n  individual calls to in-ns/require/use/import:\n\n  (ns foo.bar\n    (:refer-clojure :exclude [ancestors printf])\n    (:require (clojure.contrib sql combinatorics))\n    (:use (my.lib this that))\n    (:import (java.util Date Timer Random)\n             (java.sql Connection Statement)))",
  :bucket :var-definitions,
  :row 5753}

Well, anything involving actually checking calls should use the actual arguments, but documentation should probably use the :arglists metadata.

So I think clj-kondo is returning the correct information there — but perhaps should also return :arglists-metadata-strs or something which clients (like LSP) could use for documentation (only)?

Looks good to me, then clojure-lsp could use this new field if available fallbacking to arglist-strs

As we only use this field for hover documentation

And signature-help feature

I have a namespace of macros definitions which are required using :refer :all … is it possible to convince clj-kondo to resolve those symbols without redoing the require forms to refer to them specifically?

@jec yes. in that case you should lint that library code as well, so clj-kondo knows about the existence of the vars.

Thanks @borkdude. In my case, the macros namespace is in a dependency package. Is there a way to tell clj-kondo how to lint that code as well?

I'm trying to do this within VS Code btw.

IntelliJ + Cursive is able to resolve these macros correctly, but I'd prefer to use VS Code if I can get this to work.

@jec Yes. This info is in the readme of clj-kondo under "Project setup"

This is probably similar to how Cursive does it: the analyzer just has to see all of the code first

I think I see… you're refering to the --dependencies flag right?

yes. so if you use lein:

clj-kondo --lint "$(lein classpath)" --dependencies --parallel --copy-configs

you'll also need a .clj-kondo directory first

Adding that flag on the commandline seems to quiet the linter. But is there a way to set that in the config file? I'm not sure how to send that flag from VS Code

@jec you don't need to

once it has linted your dependencies, the vars are known

or at least should be

but the requirement is: you have to have .clj-kondo dir. can you confirm you have this?

yes I have that dir

are you saying the dependencies only need to be linted once, then the results are cached there?

yes

cool ty

well that seems to work on the commandline but it still flags these as problems in the VS Code editor…

If you can make a standalone minimal repro for that library, that I can clone locally, I could try it myself

could you also lint the file that gives problems in VSCode from the command line?

just with clj-kondo --lint src/foo.clj, no other flags

yes, linting the single file on the commandline with no other flags is quiet

Then that's weird. This is an issue for #calva then. Tell them that clj-kondo on the command line works, but not in VSCode

ty, I will try over there

Hmm come to think about it... It could be that you are using a different version on the command line than is used in VSCode. But VSCode / Calva should already have linted your deps as well btw

Which library is giving problems?

cc @pez @ericdallo

You could also try upgrading clojure-lsp and re-open your workspace

At this point it's hard for me to give other options since it's apparently a downstream problem

On the cli I'm using clj-kondo v2021.04.23 and in VS Code I'm using Calva v2.0.200

@jec which library namespace is giving the unresolved vars?

@borkdude it's not a public library, I'm working with a private codebase

I have to go now, but I will check in again later

ok, my last advice would be to upgrade clojure-lsp and restart your project. Calva has an option to upgrade clojure-lsp.

Yeah, I can test if it's a Calva or clojure-lsp issue if you have a minimal repro

hey! it looks like setting Calva's version of clojure-lsp to 2021.04.23-15.49.47 matches my cli behavior

cool

could you also upgrade lsp to see if it still works? you will have to restart vscode so lsp is going to lint your deps (that can take a few seconds, maybe a minute)

to the newest I mean

set to 2021.06.21-14.30.54 and it isn't working for me

so I guess LSP isn't automatically linting your deps. Did you restart VsCode?

I'm not sure it's a issue with the clojure-lsp version, could you just copy the macros or make a repro with them? probably you will be able to repro the issue

Try to remove .lsp/sqlite.db and .clj-kondo/.cache and restart vscode

ok, lspVersion set to 2021.06.21-14.30.54, removed those databases, then restarted vscode

it seems to be working

I'm not sure why sometimes there are users that complain about those kind of issues and it's solved removing those cache files, I'd like to improve that somehow, I just don't know how 😅

maybe because I had used a different clj-kondo version on the commandline?

or a old one via calva, yeah, makes sense I think

The command line clj-kondo doesn't interact with Calva or LSP, so that's not the reason

Next time, try removing .lsq/sqlite.db first, without the clj-kondo cache

Then we know if it's a caching problem in lsp. If not, also remove the clj-kondo cache. Then we know it's in either lsp or clj-kondo. Then also try only removing the clj-kondo cache if the problem occurs again.

That will give us more info than removing both at the same time.

Good idea