Fork me on GitHub

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, in this case :arglist-strs from 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,
  :macro true,
  :col 1,
  :name-col 11,
  :end-col 71,
  :arglist-strs ["[name & references]"],
  :varargs-min-arity 1,
  "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\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}
It probably should check for the :arglists metadata, right @U04V15CAJ?


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


Feel free to raise an issue about what should change (and optionally a PR)

Joshua E Cook17:06:49

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.

Joshua E Cook17:06:06

Thanks @U04V15CAJ. 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?

Joshua E Cook17:06:55

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

Joshua E Cook17:06:25

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

Joshua E Cook17:06:35

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

Joshua E Cook17:06:41

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?

Joshua E Cook17:06:05

yes I have that dir

Joshua E Cook17:06:27

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

Joshua E Cook17:06:29

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

Joshua E Cook17:06:31

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

Joshua E Cook17:06:14

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?


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

Joshua E Cook17:06:46

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?

Joshua E Cook17:06:39

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

Joshua E Cook18:06:15

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

Joshua E Cook19:06:14

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


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

Joshua E Cook19:06:47

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

Joshua E Cook20:06:00

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

Joshua E Cook20:06:04

it seems to be working

👍 4

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 😅

Joshua E Cook20:06:30

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.