clj-kondo 2024-05-28 | Slack Archive

yuhan14:05:00

Looking at the core function type annotations in clj-kondo.impl.types.clojure.core there seem to be plenty of low-hanging fruit - just wondering if there are any performance tradeoffs here with having too many annotations to type-check, thus only focusing on the more common or easily-misused functions?

borkdude14:05:30

I'd say just add to it, if there is a real thing to win, I mean, if the type is just going to be :any we don't really win much

borkdude14:05:41

Preferably separate issues

borkdude14:05:45

+ PRs

borkdude14:05:52

I'll first merge your current do/doto thing

yuhan14:05:53

I can't seem to use the namespace-level config to specify these annotations, is that a bug or unsupported?

(ns repro
  {:clj-kondo/config
   '{:linters
     {:type-mismatch
      {:namespaces
       {clojure.core
        {mod {:arities {2 {:args [:number :number]
                           :ret :number}}}}}}}}})

(first (mod :oops 3))

borkdude14:05:09

might be unsupported currently

👌 1

borkdude14:05:11

not sure

yuhan14:05:40

ok- I'll open an issue for that

borkdude14:05:30

I'm not sure if many people will use it like this. It's unlikely that people want to override type checking on a local basis

yuhan15:05:05

That's true, it just seemed like a strange edge case that could point at some deeper bug. I kinda expected the same functionality from config.edn and namespace level configs, or maybe it's a case where such differences aren't documented explicitly

hifumi12301:05:46

I wonder if there's something like the malli clj-kondo export for clojure.spec. This would allow one to leverage speculative to generate linters checking arity and type

2024-05-28

Channels