Clojurians Log v2

I suppose I could, uninstall the homebrew version in the interim, and then reinstall it after the release. I’ll explore that next time I would like to work on updating my Java interop.

I'll give you a link if you say what OS you are using. You could just temporary change your .el file to use the bleeding edge clj-kondo as well

or we could even make this configurable, but you can tweak it here: https://github.com/borkdude/flycheck-clj-kondo/blob/e38c67ba9db1ea1cbe1b61ab39b506c05efdcdbf/flycheck-clj-kondo.el#L64

I’m not sure the .el file uses it directly, since I am using it via flycheck integration. It would probably be easier for me to just try swapping out the binary. I’m using macOS on Apple Silicon. Ah! I retract my concern, since you are referring to precisely the integration that I am using. 😄

Sure, I can give this a try today to help test the work you’ve done already.

ok, you can download the binary from artifacts here: https://cirrus-ci.com/task/5069331787153408 make sure to remove some security flags that macOS adds while downloading it with sudo xattr -c <the-binary>

Good news, this resolved the issues, and I can proceed with improving my Java interop whenever I have time to get back to it!

Thanks for testing!

I don't really desperately need it, but it's definitely something I'm looking forward to.

Here's the PR: https://github.com/clj-kondo/clj-kondo/pull/2367/files

We're using 1.12 in production, and we use clj-kondo in dev (via LSP). We are not using the array type syntax (yet), but we are using the method value stuff. I don't think we have any non-dev code that has needed to use param-tags yet (surprisingly, perhaps?).

ah gotcha

I also updated edamame, which polylith is using, so at least you can parse byte/1 with that now, without an exception, FWIW

Well, once Polylith updates its deps 🙂

I just joined this channel because I set up a branch of Beat Link Trigger, my integration environment for DJ shows, to start taking advantage of the Java interop improvements in Clojure 1.12 now that it is at release candidate status, and the very first thing that happened was that when I tried to change a type hint for a java.nio.file method to use the new array syntax, clj-kondo flagged it as an invalid symbol and lit up with 30 other spurious errors throughout the namespace. laughcry I noticed that there had been a change to support this right about the time of the last release but that it seemed to not make it in, so I was curious when it might get released. I am glad to see that question is at least on the radar. This is a forward-looking task for me, though, I can just hold off on it until clj-kondo is ready. After all, Clojure 1.12 is not even officially released yet.

> clj-kondo flagged it as an invalid symbol and lit up with 30 other spurious errors How are you running clj-kondo?

Via flycheck within GNU Emacs.

Or if you mean how I am installing it, homebrew?

The most recent release appears to be 2024-08-01 which is before this PR was merged, so you'd need to be using the snapshot / nightly build to pick up this change...

Yes, that’s how it looked for me, hence my interest in when it will be in an actual release. I’d sooner wait for that than figure out how to use unreleased builds.

Looks like the PR hasn't even made it into the "unreleased" changelog section yet: https://github.com/clj-kondo/clj-kondo/blob/master/CHANGELOG.md

Ah, interesting! I looked around a bit for that but somehow missed it. Anyway, I have set aside my clojure-12 branch for now, it’s not like I lack plenty of other things I could be working on. 🙂

But I’ll keep an eye out for this so it can unblock that work.

I’ll update the changelogs before the release. You could perhaps download a binary from the CI builds to pre-test

merged the PR

Now released (cc @mike1452)

@borkdude Thank you! 👍

Yes, thanks, updated and got rid of my temporary intermediate build! 😄

One detail that needs to be taken care of: what if you don't want to use :redundant-ignore in some places... :)

Currently I'm thinking about the following scenario: - The :redundant-ignore is always reported at level :info, thus not breaking any CI runs - You could optionally enable this linter just to scan for redundant ignores as a one off task

hehe that's clever

I think that can be done, but this will then still trigger CI to fail etc when clj-kondo changes, which is maybe against the spirit of clj-kondo/ignore?

right... maybe then as a cli option or config entry... let me think more about this 🙂

well, you can always add an extra config on the command line with that one enabled I guess, or it can be reported as level :info

for sure it should be :info. It is not something that by default must break on CI

ok, seems like a fun idea. please post an issue

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

done

I've got a working prototype in the redundant-ignore branch:

this is killer

if you want to test it, the :git/sha is 6a97ffcd80e599d39edfe7fde5ec1686f2b3cbc1 :)