Fork me on GitHub
#clj-kondo
<
2021-06-22
>
seancorfield00:06:00

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)

seancorfield00:06:58

(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?)

ericdallo00:06:10

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

seancorfield00:06:54

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.

ericdallo00:06:20

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*])

ericdallo00:06:45

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}
It probably should check for the :arglists metadata, right @U04V15CAJ?

seancorfield00:06:43

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

seancorfield00:06:50

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)?

ericdallo00:06:14

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

ericdallo00:06:34

As we only use this field for hover documentation

ericdallo00:06:46

And signature-help feature

3
borkdude07:06:42

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?

borkdude17:06:13

@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.

borkdude17:06:02

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

borkdude17:06:23

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?

borkdude17:06:31

yes. so if you use lein:

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

borkdude17:06:40

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

borkdude17:06:09

@jec you don't need to

borkdude17:06:21

once it has linted your dependencies, the vars are known

borkdude17:06:28

or at least should be

borkdude17:06:43

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…

borkdude17:06:14

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

borkdude17:06:28

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

borkdude17:06:34

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

borkdude17:06:36

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

borkdude17:06:30

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

borkdude17:06:36

Which library is giving problems?

borkdude17:06:36

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

borkdude17:06:57

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

borkdude17:06:05

@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

borkdude18:06:09

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

ericdallo18:06:16

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

2
borkdude19:06:32

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)

borkdude19:06:42

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

borkdude19:06:37

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

ericdallo19:06:55

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

ericdallo20:06:33

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
ericdallo20:06:41

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?

ericdallo20:06:58

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

borkdude21:06:56

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

borkdude21:06:21

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

borkdude21:06:00

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.

borkdude21:06:08

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