Recently I discovered -Dclojure.compiler.direct-linking=true as a perf optimization for your production build, but you need to not have with-redef , set!, alter-var-root! and other friends of theirs used on functions otherwise you risk breaking prod. Is there a clj-kondo linter existing for this? I know I could probably do one myself but just curious if this is standardised
not standard, but you can detect those with discouraged-var
also you can avoid direct linking by marking the vars with `:reload` :redef or :dynamic
:redef not :reload
thanks
if you apply this i’d be interested to see your measured improvements. I tried this and quickly benchmarked and didn’t see anything so i didn’t try to pursue fixing all the edge cases it introduces. Would love to see measured numbers in the wild
I mean… I just read online it gives 5-15% perf boost so I believed it 😄 . Happy to be pointed to some stress testing resources for this
I would also recommend use elide-meta too for perf
I have multiple times seen a perf boost, but it really depends of course on your hot paths whether it will
hello, I ran into https://github.com/clj-kondo/clj-kondo/issues/2257 when linting a project with generated namespaces. Is there a fix planned? Also - what are the workarounds other than excluding the offending files from output?
I think it has to do with the fact this is in project.clj, and kondo not doing macro expansions, or something like that. I don't have the time to debug this now and I have good workarounds (I fixed the symbol, but excluding the project.clj was also acceptable for me). I was wondering if it's something fixable in kondo somehow (my default is always to add clj-kondo/ignore when it's some edge case but it didn't work this time).
project.clj and macroexpansions? what does this have to do with invalid symbols?
I don't have the time to debug this like I said, but it happens when I lint project.clj due to symbols like a/b/c, although lein runs fine (and they use the same reader I assume).
I think this is a minimal example of the difference. This code runs fine but breaks in kondo:
> cat k.clj
'a/b/c
> clj-kondo --lint k.clj
k.clj:1:2: error: Invalid symbol: a/b/c.
k.clj:2:1: error: :quote node expects 1 value.
linting took 5ms, errors: 2, warnings: 0
> cat k.clj | clj
Clojure 1.12.1
user=> a/b/c
user=>
I don't think it's good to use it, as Clojure's states symbols should have a single / , but it does run."it does run", yes that's the point I was trying to make above. clojure doesn't check this, but the tooling around clojure is built around the assumption that you will not use this. tools.reader will crash. this is used by clj-kondo. but Clojure has its own internal reader which is more "permissive"
but perhaps we'll have to fix this anyway so I don't have to have this discussion ;)
I'll take a look if this is fixable
ok, just pointing out that I ran into this as well. I fixed it for me but I also think it's valuable to write it here. FWIW I do think it should be checked by kondo, but more like the other linters (with similar controls).
yes, it makes sense for a linter, doesn't it ;)
Thanks for the repro:
$ clj -M:clj-kondo/dev --lint - <<< "'a/b/c"
:1:2: error: Invalid symbol: a/b/c.
:2:1: error: :quote node expects 1 value. @reut.sharabani Good news, I finally fixed it on master. It was a bit more work than I expected, but now it works :)
Can you fix the code which generated invalid symbols? It's just not supported by Clojure
I mean, it's accidentally allowed in Clojure, but not by all the tooling surrounding Clojure including tools.reader
yes, excluding files from output is a good solution there's also a different setting for this, let me check
yeah, output + exclude-files is the only option for this
another option is to process the directories you're linting using a script or whatever and filter out the generated directory
if you're experiencing this via clojure-lsp, there's other options too