Fork me on GitHub
#clj-kondo
<
2019-07-30
>
borkdude07:07:38

why would you only want to exclude key fn args? e.g. (defn -main [& [a b c & _ :as args]]) might also fall under this behavior?

borkdude07:07:54

user=> (defn main [& [a b c & _ :as args]])
#'user/main
user=> (doc main)
-------------------------
user/main
([& [a b c & _ :as args]])
same thing if you ask me, you destructure for the doc benefits

borkdude07:07:31

so maybe this setting should be named something like :exclude-destructured-public-args to emphasize it will only happen in public functions created with defn and defmacro?

lee12:07:13

Iโ€™m probably not using the correct terms. If I RTFM simple_smile https://clojure.org/guides/destructuring , I am suggesting that this option wonโ€™t ignore unused sequential destructuring, for example:

(defn print-coordinates-3 [[x y z]]
  (println "x:" x ", y:" y "))
would still issue a warning about unused z.

borkdude13:07:37

I think so yes

lee13:07:13

so thatโ€™s why I introduced the word keys but it might not be the right word. :exclude-associative-destructured might be closer to correct?

borkdude13:07:08

a vector is also associative

borkdude13:07:19

so keys is better if you want to exclude vectors

borkdude07:07:26

or maybe you are destructuring only for yourself, not for a public consumer, so :exclude-destructured-fn-args seems best to me

borkdude09:07:13

anyone wants to play with this data https://github.com/borkdude/clj-kondo/tree/dump-analysis/analysis#data before I release it tomorrow?

sogaiu10:07:22

@borkdude it looks interesting! unfortunately, i don't have the set up to try it before tomorrow -- unless just building the dump-analysis branch is enough? is it correct that the filenames will be full paths or is that based on what is passed in originally?

borkdude10:07:42

it's based on what you pass in originally, but it's possible to make that configurable, if you need that. I could also include the jar file names if you want

borkdude10:07:43

that could also be useful for the linter itself. {:output {:filenames :absolute}} or something

sogaiu10:07:08

iiuc, because from other tooling it's not possible to know what the classpath was when the analysis was done, i'm not sure i can reliably determine the exact files in question. i hope it can be worked out appropriately ๐Ÿ™‚

borkdude10:07:25

it can, because it reads them

sogaiu10:07:18

sounds good ๐Ÿ™‚

borkdude10:07:19

I think this can be implemented as a seperate issue: https://github.com/borkdude/clj-kondo/issues/383

sogaiu10:07:15

possibly on a related note, would it be possible / useful to be able to recover the classpath that was used at the time of analysis?

borkdude10:07:49

I could just return the :lint option that was used, that would be the most flexible, so what you pass in, you get out

borkdude10:07:43

I don't see yet how that would be useful, since you know what you passed in already

borkdude10:07:02

note that when you call clj-kondo with an absolute path, you will already get an absolute path back

sogaiu10:07:46

i was thinking whether tooling might make use of a user's previous invocation of clj-kondo -- so the tooling wouldn't necessarily know what was used for the classpath

borkdude10:07:12

wouldn't the tooling itself invoke clj-kondo?

borkdude10:07:56

if absolute paths are included in the output, return the lint arguments doesn't add much value I think for tooling

borkdude10:07:03

since the tooling already knows where to find those files?

sogaiu10:07:06

it might, but the user is the one who knows what classpath they want, and if the tool could just read that info from somewhere (e.g. if clj-kondo stored it in its cache), then the tool doesn't have to bother the user about it

sogaiu10:07:50

i was actually thinking to use clj-kondo's api to make an extension / plugin -- not ask the user to install clj-kondo

borkdude10:07:06

in the JVM right?

sogaiu10:07:19

actually, i was going to build a native-image binary

borkdude10:07:43

but then you will need to have clj-kondo installed, I don't get it

borkdude10:07:58

are would you bundle clj-kondo with your binary

sogaiu10:07:59

no, it is not necessary, because clj-kondo provides an api

sogaiu10:07:09

clj-kondo can be used as a dependency

borkdude10:07:18

right, that's true

sogaiu10:07:19

i think i tried this already a bit back

borkdude10:07:36

in which editor were you going to use this?

sogaiu10:07:17

this is part of the experimental project to make editor independent tooling -- so far the editors i have been experimenting with are emacs, atom, and vscode

sogaiu10:07:26

they all use the same native-image binaries

sogaiu10:07:35

and provide thin "glue" to talk to it

borkdude10:07:26

let's just start with the things you need concretely, without speculating too much. I'll add the full file paths option for starters

sogaiu10:07:50

thanks! that'd be great -- i am hoping to implement "find definitions" for starters

borkdude10:07:34

so the full file path for e.g. clojure.core/defn would be in my case /Users/borkdude/.m2/repo/../../../clojure-1.10.1:jar:clojure/core.clj but if you're linting only one file without any dependencies like clojure itself, defn is resolved from a built-in cache which has no filenames

borkdude10:07:28

so it all depends on what your editor tooling is linting. you can ask the user to index your entire classpath whenever one of the dependencies change

borkdude10:07:40

and then you can save that analysis information somewhere

borkdude10:07:12

but I guess you don't have to wait for this, just invoke your binary with a full path

lee12:07:07

I am thinking about eventual use of clj-kondo from cljdoc. Cljdoc takes the convention (and code) from codox to exclude namespaces/fns/vars marked with :no-doc metadata. Would this be possible with clj-kondo?

borkdude13:07:09

@lee I can include that metadata in the analysis data

lee13:07:26

that would do the trick!

borkdude13:07:31

I think including :deprecated is also good

borkdude13:07:07

maybe docstring as well?

borkdude13:07:37

I don't currently save that anywhere

borkdude13:07:49

I do have a linter for misplaced docstrings in defn

borkdude13:07:42

thank you, I'll add that link to the issue

borkdude13:07:14

I'm not sure if I'll get everything in before tomorrow's release, but you won't be using it anyway before import-vars is supported

borkdude13:07:27

and I expected the latter to be a bit more involved, but not undo-able

borkdude13:07:14

I want to introduce the concept of a redirect, so when you do (def a 1) (def b #'a) which I think is what import-vars is doing, then var b is redirected to var a, so when you call b, you also call a

borkdude13:07:36

and then I'll have to analyze import-vars and make use of this new redirect concept

robertfrederickwarner21:07:18

Is it possible to disable all :unused-namespace warnings for a given namespace? I'd like to disable it for my dev namespace (my usual home at the repl) as it brings in a variety of utility functions to make them available while developing

borkdude22:07:35

@robertfrederickwarner you can using a namespace local config

borkdude22:07:51

but you can also solve that with declare

borkdude22:07:21

or you can avoid using use and refer :all (although clj-kondo is able to resolve them when you use a cache)

robertfrederickwarner22:07:49

Thanks. I'll probably go with the namespace local config - seems the most minimal

robertfrederickwarner22:07:14

Absolutely love the tool, it's helped clean up a bunch of code in the past two weeks or so I've been using it

borkdude22:07:51

good to hear ๐Ÿ™‚

robertfrederickwarner22:07:07

I've put in the local config and toggle syntax checking on and off (my usual routine after modifying my kondo config), but it doesn't appear to be working

borkdude22:07:51

the namespace local config doesn't work for all linters yet

borkdude22:07:03

I thought you were only speaking about unresolved symbols

borkdude22:07:18

but when you remove the alias (since you don't need it) clj-kondo won't report that as unused

robertfrederickwarner22:07:18

ah. i guess because this is linting a namespace that would make sense

borkdude22:07:46

so only [clojure.core.async]

borkdude22:07:02

you can also just exclude your dev file from the linting output if you want

robertfrederickwarner22:07:57

nah, i'll just leave it for now - would like to still have linting throughout the rest of the file. not a big deal.. just trying to clean things up as much as possible