Fork me on GitHub
#clj-kondo
<
2022-10-19
>
Noah Bogart21:10:37

I opened an issue about adding a linter from eastwood to clj-kondo. Would you (borkdude) be interested in adding other linters from eastwood and kibit?

borkdude21:10:23

let's discuss on a case by case basis.

👍 1
nooga23:10:53

I'm using vscode to edit let-go files, which are mostly valid Clojure. I get Can't parse myfile.lg, No matching clause: :unknown [Ln 1, Col 1] from clj-kondo(syntax) in almost every file, regardless of the content, always on the first line. It only happens when the files have .lg extension - I've associated it with Clojure though. Is there a way to make clj-kondo respect .lg 🙂?

nooga11:10:28

1. make sure your VSCode global settings.json has the following set:

"files.associations": {
    "*.lg": "clojure"
  },
2. create an empty folder and open it in fresh VSCode window, 3. create and open file foo.lg 4. In foo.lg paste
(ns foo)

(println 1)
result:

nooga11:10:00

the error goes away when you rename foo.lg to foo.clj

borkdude11:10:46

I'll test in emacs as well

👍 1
borkdude11:10:09

In emacs it works fine when I enter clojure-mode this is because flycheck-clj-kondo derives the language fallback from the mode you're in https://github.com/borkdude/flycheck-clj-kondo/blob/ff7bed2315755cfe02ef471edf522e27b78cd5ca/flycheck-clj-kondo.el#L88-L91 but I'll make clj-kondo more lenient that when the language is unknown it falls back to clojure

borkdude11:10:55

O wait, this is already the case:

$ clj-kondo --lint /tmp/foo.lg
/tmp/foo.lg:5:1: error: Unresolved symbol: x

borkdude11:10:22

I suspect that clojure-lsp is passing lang as lg or so:

$ clj-kondo --lint /tmp/foo.lg --lang lg
/tmp/foo.lg:0:0: error: Can't parse /tmp/foo.lg, No matching clause: :lg

borkdude11:10:34

It should just not pass --lang if it's something unknown. cc @UKFSJSM38

ericdallo16:10:13

I thought we fixed that, I'll take a look

ericdallo21:10:25

Fixed on master, it will only pass lang if not unknown, available on nightly build

❤️ 1
skynet23:10:00

it looks to me like I'm getting from the new :unused-value linter on a macro from a library I'm using. specifically this one: https://github.com/ptaoussanis/nippy/blob/a2e03bef5e3aaabb1351367085334cf8feadcd06/src/taoensso/nippy.clj#L1939-L1968 maybe :unused-value should be disabled for things inside macros?

borkdude06:10:49

Please provide a repro as in a file which I can readily lint locally

skynet17:10:43

sorry, I'm not able to reproduce it outside of the project it's in: https://github.com/skynet-gh/skylobby/blob/master/graal/clj/skylobby/core.clj#L37-L39

$ clj-kondo --lint graal/clj/skylobby/core.clj | grep Unused
graal/clj/skylobby/core.clj:37:3: info: Unused value
graal/clj/skylobby/core.clj:43:3: info: Unused value
it must be something weird with my setup

borkdude17:10:20

I'll clone your repo

👍 1
borkdude18:10:08

It does seem to be related to the config, when I move it aside the warning disappears. Looking further

borkdude18:10:29

oh yikes: .clj-kondo/cnuernber/dtype-next/taoensso/nippy.clj

borkdude18:10:48

It seems that dtype-next provides a config for nippy, that's not how things should work :)

borkdude18:10:54

yes, it's related to that one

borkdude18:10:21

but then again, I think it's also probably better to ignore unused values generated by macros

borkdude18:10:33

so I'll check if there's a fix for that as well

skynet18:10:17

oh, I should probably fix that and gitignore those other files in .clj-kondo right? I've started using this .gitignore in .clj-kondo folder on new projects:

*
!.gitignore
!config.edn

borkdude18:10:23

it's ok to keep that config in .clj-kondo in source control

borkdude18:10:36

but dtype should just not include config for other libs

skynet18:10:42

I see, thanks for looking into this so deeply!

borkdude18:10:11

When I change the dtype next config for extend-freeze to this:

borkdude18:10:17

(defmacro extend-freeze
  [_dt _kwd argvec & code]
  (let [[buf-var out-var] argvec]
    `(let [~buf-var 1
           ~out-var 2]
       ;; (type ~dt)
       ~@code)))

borkdude18:10:41

Then it works as expected, since I ignored the dt argument (which is the File symbol)

👍 1