clj-kondo 2023-11-06 | Slack Archive

Alexander Kouznetsov18:11:11

I have a codebase with ~~2500 namespaces and~~ 400 custom macros and running clj-kondo for it currently generates ~~700 errors and~~ 400 warnings. My goals it make clj-kondo stop producing any false positives for this codebase and I estimate that I might need to create hooks or lint-as rules for each of these macros. I’m wondering if there are any good shortcuts or supporting libraries or tools that make creating these hooks or lint-as rules easier? One random idea that I have is that hook generation code might often be created with something similar to syntax quoting - which helps generates hooks that simply rewrite the existing code into something that clj-kondo can understand. I’m wondering if somebody had a similar idea. In my vision a defmacro definition may include such a thing in its attrmap to introduce a replacement code for a hook. Something like this: (defmacro x {:clj-kondo/rewrite '(let [a {} b c] body)} [a b c & body] …) . Thoughts?

borkdude20:11:01

Hey @UHS6PHL31 - it's an interesting idea, but right now you can almost achieve the same with

{:hooks {:macroexpand ...}}

The inline notation will imo lead to confusions, e.g. people will try to write things that refer to code outside of the form using syntax-quote perhaps.

👀 1

Alexander Kouznetsov02:11:27

Thank you very much for your reply. This is quite interesting. I overlooked this initially. I’ve read the description in https://github.com/clj-kondo/clj-kondo/blob/master/doc/hooks.md#macroexpand and I’m puzzled by a few things: 1. It might be a bit confusing to have the same-named macro in the same-named namespace with potentially the same content only distinguishable by a path. Why does it need to be exactly the same (namespace and macro naming)? 2. The doc claims that locations info will be lost in some cases. Where can I find more detailed info about such cases and potential explanations about why the locations will be lost (or more importantly, how to use it so that no locations will be lost?) 3. How complex can be a macro in configuration, can it use syntax quotes, etc? What would determine whether a macro can be used as is for its config macroexpand macro? Maybe such macros can be configured to macroexpand automatically or by flagging them with some attr-map value? I guess I will have to try to see how #2 and #3 work. #1 seems to prevent macros from being reused - for example I have a number of macros defined in different namespaces that each can be potentially configured with the same macroexpand macro. Would it be possible to share a single implementation in such case?

borkdude05:11:55

Yes, just point multiple times to the same macro in the config

Alexander Kouznetsov19:12:23

:macroexpand is a killer feature. Why isn’t it on by default for any arbitrary macro?

Alexander Kouznetsov19:12:02

Thanks for pointing me to it.

borkdude20:12:36

Because not all macros are pure functions without any external dependencies, it would be hard to make that work in general

2023-11-06

Channels