Clojurians Log v2

Ah, there are two def db-spec forms, both in comment forms. This one is the first in the file. Much further down the file the second one does indeed define db-spec to have those keys. So, it seems like the analysis here is using the wrong definition?

(I worked around it by renaming this db-spec to ds-spec and leaving the other one alone, but this still feels like a bug)

Another way to look at this is to take either one of the defs as the source of truth or the merged version...? or ignore if a redefinition exists?

or ignore (def x some-map) as input for unknown map key completely?

Note that the issue doesn't just exist with comment forms. without the comment forms there's also ambiguity

Right, but if I have code like this:

(def x some-map)
(use-map x)
(def x some-other-map)
(use-another-map x)

exactly. and then the point about comment forms, those should likely be ignored right?

Not sure why comment is relevant here, since the code flow is still linear.

since comments are not executed in production

Hang on, if I had those four lines, not in comment forms, would the analysis be done correctly, i.e., following the "should" parts of my question?

btw in

(def x {:a 1})
(defn f [] (:b x))
(def x {:b 2})

That's not the case I'm talking about tho' 🙂

I know but it's an extra point to consider. I'll now closely look at your case

yeah your case isn't common at all. usually lookups will be inside functions, not in top level forms. it's very much related to my later point in that sense

why are you even re-defining vars. you make things too hard for me Sean! ;)

Okay, that's a reasonable explanation. I was just surprised since it is linear top-level code (albeit inside two distinct comment forms, hundreds of lines apart).

Maybe I'll just shut off the check when there's conflicting data about a var

TBH, I probably didn't even notice I was re-def'ing db-spec until I tripped over this new linter—and the code has been like this for years.

and/or ignore comment forms

Linting in comment forms is great! I would hate to lose that.

yeah I mean with respect to missing keys

Perhaps the second form's def could be flagged as a potential redefinition?

That would have caught my eye and I might have renamed one of them, or removed the second definition (and changed its use!).

What I mean is: 1. when multiple defs exist ignore this data for unexpected keys 2. outside of the comment forms, there's already a warning for re-defined vars

does that make sense to you?

Perhaps the second form's def could be flagged as a potential redefinition?

This should get rid off your false positives at least: https://github.com/clj-kondo/clj-kondo/pull/3054

Ah, interesting (inside vs outside comment for re-def). Yeah, that makes the unexpected keys linting tricky. Sad to lose it inside comments but I can see the complication now.