Fork me on GitHub
#clj-kondo
<
2022-01-27
>
pinkfrog13:01:54

Yup. Just found out it too. Thanks

pinkfrog13:01:28

I remember previously the doc mentions next.jdbc and now that piece is missing. Maybe my memory is wrong.

borkdude13:01:29

don't remember that

pinkfrog14:01:20

I am importing java.sql.Savepoint but I’d like to use java.sql.Savepoint as the fullname instead of only Savepoint. Clj-kondo is now complaining unused import of java.sql.Savepoint.

pinkfrog14:01:31

Is it a Bug?

Alex Miller (Clojure team)14:01:38

you don't need to import if you're using the full name

Alex Miller (Clojure team)14:01:11

import just makes Savepoint resolve to java.sql.Savepoint, it's not actually need to cause loading or anything

pinkfrog14:01:13

I suspect I shall manually import the java class first for the JVM to load it.

Alex Miller (Clojure team)14:01:30

no, you don't need to do that

Alex Miller (Clojure team)14:01:13

it's different than require

pinkfrog14:01:34

Cool. Thanks.

pinkfrog14:01:41

Just to make sure, the JVM loads the java.sql.Savepoint only when I use it, right? And this magic is performed by clojure runtime under the hood.

Alex Miller (Clojure team)14:01:48

when you need the Class object it will be loaded

Alex Miller (Clojure team)14:01:40

(and import does not load)

borkdude14:01:45

> when I use it, right Slight clarification: it's being loaded when the compiler resolves the class name, not when the interop on that class is actually executed.

borkdude14:01:12

So when you have a file like:

(ns foo) java.sql.Savepoint (defn foo [])
and you load that namespace, then the class is also loaded

thanks3 1
borkdude20:01:35

OK, this cool PR by @pfeodrippe was just merged to master. clj-kondo should now be able to infer some more type-related errors with (nested) maps. As this was a non-trivial commit, please lint your sources and report any regressions :) You can do so with:

clojure -Sdeps '{:deps {clj-kondo/clj-kondo {:git/url "" :git/sha "bcad7ea524d0c706c77610c829298a118220ee29"}}}' -M -m clj-kondo.main --lint src
(replace src with your source(s))

🎉 7
pfeodrippe21:01:58

You did all the grunt work in the end, thanks, man o/

mknoszlig21:01:32

i’m guessing this is out of scope for the PR, right?

(let [{:keys [c]} {:c :f}]
  (inc c))

borkdude21:01:13

that would would be a good one to support as well

borkdude21:01:14

I guess we could treat {:keys [c]} as (:c ...) and then continue with the code as usual

borkdude21:01:21

issue (+ PR) welcome

Joshua Suskalo21:01:47

Just as a heads up, I'm getting this error on clj-kondo 2022.01.15

Suspicious state from syntax checker clj-kondo-cljc: Flycheck checker clj-kondo-cljc returned 2, but its output contained no errors: /home/jsusk/Programming/Projects/Clojure/farolero/src/cljc/farolero/core.cljc::: warning: Missing catch or finally in try
linting took 167ms, errors: 0, warnings: 1

Try installing a more recent version of clj-kondo-cljc, and please open a bug report if the issue persists in the latest release.  Thanks!
when running on my project farolero. It is correct that there are try without catch, but it seems to be getting confused about the location. https://github.com/IGJoshua/farolero/blob/master/src/cljc/farolero/core.cljc#L82-L88 🧵

1
Joshua Suskalo22:01:34

So it's intentional that there's a try without a catch here, specifically because the intention here is that I want to prevent a recur to the function there.

Joshua Suskalo22:01:03

I'm perfectly fine with kondo emitting a warning, but it's not specifying a source location, and I'm confused why.

borkdude22:01:03

makes sense. you can stick a #_:clj-kondo/ignore for that case

Joshua Suskalo22:01:16

Maybe it's a bug that it's not got the source location?

borkdude22:01:28

I'm not sure. Are you using a hook to lint this code? Then there might not be a location attached to the node

Joshua Suskalo22:01:19

Oh, yeah, that's probably true because it's one of the constructed nodes that's added to the code.

Joshua Suskalo22:01:42

So how could I fix this, do I need to emit a comment node or something to tell kondo not to lint my macro with this linter?

borkdude22:01:22

you could just remove the try perhaps and make it a do or so

Joshua Suskalo22:01:56

Right, but then kondo wouldn't complain about recur there

Joshua Suskalo22:01:12

and that's why the try was put in there in the first place

Joshua Suskalo22:01:54

I think I could just emit an empty finally block

Joshua Suskalo22:01:56

that might work

Joshua Suskalo22:01:55

That worked. Glad it's not a bug.

Joshua Suskalo22:01:02

Thanks again for kondo, I love it!

borkdude22:01:17

Thank you :)

borkdude22:01:32

Perhaps clj-kondo should not emit warnings without a location

borkdude22:01:42

but on the other hand, you do catch some issues like this, if it does

Joshua Suskalo22:01:12

yeah, so far every time it's emitted a warning without a location it's been something that told me something was up with my hooks, so I think they're useful.