Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-05-24

Channels

#clj-kondo
<
2023-05-24
>
Carlo10:05:10

clj-kondo displays a: Expected: map, received: seq (probably derived from malli annotations), in a function call that expects, and gets, a seq. I would like to understand why clj-kondo thinks it's a map instead. Believing it could be a stale cache problem, I deleted .lsp/.cache, but the annotation is still there. Any idea?

borkdude10:05:48

I don't have any idea without a reproduction

Carlo10:05:24

thank you, let me try to get a repro case 🙏

Carlo10:05:39

Here's a repro: 

(def foo [:* :int])
(malli.core/=> bar [:=> [:cat foo] :keyword])
(defn bar [f] :ok)
(bar [1 2 3])
[1 2 3] is underlined, and the error is expected: integer. received: vector

Carlo10:05:03

I updated my version of malli and the error is still there. If you can't reproduce it @borkdude I can try bumping my clojure-mode

Carlo10:05:02

No, I see, it's an interaction between the malli :cat schema and :*. I though using [:vector :int] was the same but that was just because my emacs took a bit to update and clerk was messing with malli instrumentation. If I just use [:vector :int] , re-eval everything and then wait, the error is gone. thank you @borkdude!

lassemaatta10:05:22

I don't use malli, but I think https://github.com/metosin/malli#sequence-schemas describes this behaviour. Check the example after the "As all these examples show, the "seqex" operators take any non-seqex child schema..."

ericdallo17:05:56

yes, thank you :)

borkdude18:05:19

This false positive can be traced back to Eastwood flagging swap! as a pure function or so I think

borkdude18:05:27

I’ll still have to look into it but I’m on a trip in London right now. Any research will be appreciated meanwhile :)

👍 4
ericdallo17:05:34

I bumped kondo in clojure-lsp and tests started to fail, after some bisect, I found that this https://github.com/clj-kondo/clj-kondo/commit/deb8326a24d610b9756989d83d6abb8efde70fa3 made that, any thoughts @borkdude?

ericdallo17:05:32

I think it's related with :clj-kondo/unknown-namespace removal as you mentioned before, I thought we didn't use, but I was wrong 😅

borkdude19:05:30

I don’t think it should have been in the analysis but perhaps you could explain what you were using it for

ericdallo13:05:18

it has some logic to check if the var-usage has a :clj-kondo/unknown-namespace on :to to return the element itself, for example https://github.com/clojure-lsp/clojure-lsp/blob/8a8b47955c976f3ce0977889f95cd5f3a7058608/lib/src/clojure_lsp/queries.clj#L490. So, for a code like: 

(ns foo) 

bar
AFAICS, now clj-kondo doesn't return any analysis for bar where it used to return something like: 
{:end-row 488,
 :name-end-col 8,
 :external? false,
 :name-end-row 488,
 :name-row 488,
 :name bar,
 :from foo,
 :col 1,
 :name-col 1,
 :context {},
 :uri "...",
 :end-col 8,
 :bucket :var-usages,
 :row 488,
 :to :clj-kondo/unknown-namespace}

ericdallo13:05:08

without analysis we can't even know that element exists, so find-references can't return that element itself, and other features wouldn't know that exists, like hover, document highlight, semantic tokens

borkdude13:05:07

right, ok, let's add it back then, it's a one line change in the analysis ns

👍 2