with :lint-as probably

Heh, funnily enough, I was adding this to Potemkin this weekend

@U10EC98F5 Adding this? I am writing a lib, so I don’t wanna the user to tweak with :lint-as.

If you come up with some good hooks, please share? :lint-as worked for many, but I still need to straighten out how import-vars works when I get back to it.

@U04V15CAJ Do you have any thoughts on how to achieving lint-as with import-vars from a lib ?

@UGC0NEP4Y clj-kondo should just add support for the multi segment potemkin namespace. @U10EC98F5 what is the final name going to be?

@U04V15CAJ Looking at the docs, https://cljdoc.org/d/clj-kondo/clj-kondo/2022.06.22/doc/configuration#exporting-and-importing-configuration, it seems it is impossible to automatically enable the lint-as configuration . The user must activate that on its own.

imported configs are now automatically activated, if you stick to the suggested format

I wasn't planning to change the Potemkin namespaces unless necessary. Barring some Graal user complaining, that's unlikely

@U10EC98F5 Then I misunderstood.

Heh, funnily enough, I was adding this to Potemkin this weekend

perhaps potemin isn't problematic with graalvm since it runs at compile time

> I was adding this to Potemkin this weekend I meant I was adding useful clj-kondo hints 😄

On that note, a question: If I use a macro hook to transform import-vars :

(import-vars [ns1 foo bar]
             [ns2 baz qwerty])

(def foo ns1/foo)
(def bar ns1/bar)
(def baz ns2/baz)
(def qwerty ns2/qwerty)

(defn import-macro*
  ([sym]
   `(def ~(-> sym name symbol) ~sym))
  ([sym name]
   `(def ~name ~sym)))

(defmacro import-fn
  ([sym]
   (import-macro* sym))
  ([sym name]
   (import-macro* sym name)))

> is that correct for teaching kondo about the defs? Yes - clj-kondo could do a better job seeing the connection between two vars. There is an issue about this

Good news! What’s the issue #?

https://github.com/clj-kondo/clj-kondo/issues/412

Feel free to upvote with a thumbs up or if you're really keen, you could try to work on. I kinda know what needs to happen, so I could guide you

Are there any code/branches I should look at? I’m not sure if/when I’ll get to it, but Potemkin (and proto-Potemkin) fns are all over Zach’s aleph/manifold/etc code, and I’m tired of staring at a sea of linter warnings. 😅 I can’t really use it for all the false positives.

Hmm, I could maybe help you with that, if you could give me a starting point

@U10EC98F5 There is a "proxy var" construct in clj-kondo based on what it detects based on the potemkin macro

And this same mechanism could be used for (def x y)

Huh, I hadn’t realized potemkin had special code already

yes, there is special code in clj-kondo to support the usage of potemkin

but this is based on potemkin/import-vars usage

Well, import-vars was my starting point

it already has support for that

you need to lint your project sources first though

before it can make the connections

But it doesn’t yet support the other issue, right? Understanding the arity of the “imported” vars

I think it does

there's test cases you could look at

Sure, I’m happy to take a look. I just checked, and it definitely doesn’t understand the import-fn macro’s arity, though

https://github.com/clj-kondo/clj-kondo/blob/a550a8279e1bf2134921d5a31b98aa68c60f5a00/test/clj_kondo/main_test.clj#L2429

I thought you were referring to the arity of the imported var, not the import-vars macro itself. Perhaps you can just submit a failing test or so, I think we're talking past each other ;)

I added (import-fn unify-gensyms uniqlo) at the bottom of potemkin.clj, and I thought it would know that import-fn has a 2-arity version where the second one is a new symbol, and I thought I got the :macroexpand hook for that correct

SOrry about that

clj-kondo only has support for import-vars - I've never heard of import-fn

If you add that snippet, does it complain about uniqlo?

Ah, ok

but it could be potentially have that if it's a variation, I just don't know that construct

I think import-vars is really the important one. It uses import-fn under the hood

And hell, some of the potemkin stuff should also be discouraged…

import-fn is not important per se, I was just trying to figure out what, or if, I was doing wrong when adding my own hook for it

maybe you could have a hook which expands that into import-vars 😆

and then it should work

and that’s how he froze his computer tonight

WOuld it be an infinite loop?

no, because clj-kondo handles that code directly, it doesn't expand to import-fn

Cool, well, I shouldn’t let the perfect be the enemy of the good. Even linting many of these should clear up a lot of linter warnings, I hope

In JVM Clojure, you don't get any arglists metadata for that. clj-kondo could do this, but why?

I'm presuming the reason that LSP is able to show function arguments for defn functions and not fn functions is because clj-kondo provides more details about the defn. My rationale is that they're both accomplishing the same thing and it would be more consistent for clj-kondo to be able to provide as much of the same data as possible on both forms. But if you don't think it's a reasonable thing I think I can figure out how to do it by using something like clj-kondo.impl.analyzer/analyze-fn-arity. Looks like some of the tests use a fairly small ctx map in places where it's needed.

I think we could add this info. But why not just use defn instead?

Good question 🙂 I don't know why people opt for the (def (fn approach, but they do. As for myself, I'm hacking away on a Clojure code exploration tool that leverages clj-kondo, so I'm at the mercy of the community.

OK, issue welcome. clj-kondo itself tracks arity info for this:

$ clj-kondo --lint - <<< '(def f (fn [])) (f 1 2)'
<stdin>:1:17: error: user/f is called with 2 args but expects 0

Okay, thanks very much. I'll create an issue to track this.

https://github.com/clj-kondo/clj-kondo/issues/1760