It’s a known issue, but not one we plan to address in Clojure afaik. I would say don’t use two source files that are the same insensitive to case

Seems like some lib ran into this years ago, but maybe that was specifically with vars (which may become classes on disk at some point), maybe it was camel-snake-kebab?

https://github.com/clj-commons/camel-snake-kebab/issues/15 is the issue I’m remembering

the clj-kondo 2006 issue is about vars which get compiled to classes as well

I guess it's better to avoid it then, would it be good to make this a default linter (as opposed to opt-in)?

Java also has this problem btw.

https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022267.html

https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022222.html

right, if anything, this should be solved at the level of the JVM, rather than clojure

I looked a bit deeper into this and when I compile a namespace like this:

(ns scratch)

(defn Foo1 [])

(defn FOO1 [] (Foo1))

What kind of filesystem?

macos

let me check the filesystem

Mac is insensitive but preserving by default

APFS

So in checking the class on the second one it will look like it’s already there

(Mac does Unicode normalize though, which can cause its own issues)

So, this is the expected (confusing) behavior and the reason you should not do this :)

cool, I thought it was only a problem on Windows, but it seems there's even more reasons to avoid it :)

@UR1CCJ8MS implemented this linter and I'm finding various cases like this. E.g in transit-clj:

(deftype Reader [r])

(defn reader [])

For a full list of potentially false positives: https://github.com/clj-kondo/clj-kondo/pull/2009#issuecomment-1467764894

Ah the non-issue between deftype Reader and defn reader is that reader is emitted as classes/scratch/reader.class but Reader is emitted as classes/scratch/scratch/Reader.class , so no conflict

OK, so it looks like we should consider definterface, defprotocol, defrecordand deftype as one set of names, and defn, defn-, definline and defmacro as another set, and look for conflicts within each set but not between them?

yes, I guess we could just collect a bucket of names and prepend the namespace name to those definterface etc with a dot, similar to how it's done on disk, or so

or maintain two different buckets for each kind