Clojurians Log v2

It's probably that import line, thanks! I must have missed that in the docs. I am just seeing my aliases not being valid symbols when used later, clj-kondo doesn't realise defalias binds something that that symbol. Even when I configured defalias to mean def which is interesting.

Huh, even with the configs in .clj-kondo, I still see an error here. Probably still user error, sorry about the screenshot...

No that's legit. Not sure what to do about that.

It's a false negative in general since clojure doesn't resolve symbols there. cljs might.

This horrible hack should suppress the warning ^{::t/unsafe-cast ^:fake-quote 'TypedClojureExInfoData} . I think either clj-kondo needs to tighten its rules about metadata, or the defalias hook needs to register fake vars during clj-kondo so they can be resolved.

the latter might have nice side benefits like jump-to-definition

> It's a false negative in general since clojure doesn't resolve symbols there. cljs might. can you give an example of this as a standalone snippet?

@borkdude this is Typed Clojure living on the edge, but sure: The first 3 are false negatives and the last is a true negative (using https://clj-kondo.michielborkent.nl/):

^{:foo (a)} identity
^{:foo (ab)} (identity 1)
^{:foo (abc)} (:foo {})
^{:foo (abcd)} (fn [])

AFAICT metadata on symbols and non-macro calls in expression position are never evaluated in Clojure (they're quoted). Some macros have special handling of &form meta like -> and fn.

These are more false negatives AFAICT:

(let [^{:foo (a)} foo identity] foo)
(fn [^{:foo (aa)} foo] foo)
(fn ^{:foo (bar)} [])
^{:foo (bar)} (do)
(fn ^{:foo (bar)} a [])
(let [a 1] ^{:foo (a)} a)
(fn [a] ^{:foo (ab)} a)

There's something that's inconsistent between clj and cljs but I can't remember what. Maybe it's metadata passed to def or defn. One is evaluated the other is quoted. EDIT: it's this:

^{:foo (bar)} (defn a [])

> The first 3 are false negatives Do you mean false positive?

false negative is when something that should be reported isn't reported

anyway, perhaps clj-kondo could do a better job of not warning about this, but then again, cases like this do evaluate the metadata:

user=> ^{:foo (a)} {}
Syntax error compiling at (REPL:1:8).
Unable to resolve symbol: a in this context

yes false positive

it's context sensitive, fn also evaluates

yes

I know since I had to implement all of that in SCI 😅

that's why it's not a great idea in the first place. it's pretty useful given how typed clojure works, but I don't blame you if you don't want to wander into this undocumented area.

recently I had a nice bug in bb + meander. meander stored stuff in the type :tag , like & which wasn't a class. bb evaluated that a bit too early (which caused an unresolved symbol). clojure only evaluates :tag (in the compiler) when it encounters an interop form

Oh, there might be a quick and isolated solution to this if you're willing to do something Typed Clojure-specific. The next version has type checking opt-in via (ns ^:typed.clojure foo) . Basically you know you're in a Typed Clojure file if (-> *ns* meta (contains? :typed.clojure)) is true. My idea was to have clj-kondo default to assuming metadata is not evaluated if you're in a Typed Clojure file. Other quick solutions might be to ignore the value of :typed.clojure qualified keywords in meta maps.

I can also help with a real solution if you want to support this for real.

it should work out of the box

what is the warning you're seeing?

you might need to import the rules, they're packaged in one of the typed clojure jars

something like clj-kondo --lint "$(clojure -Spath)" --copy-configs --skip-lint

maybe the :dev alias also needs including