Cursive doesn't recognise overridden Clojure function

[danielcompton]

In the Storm project there is a function filter-key in backtype.storm.util. If the util namespace is :use'd in another namespace and filter-key is used, Cursive highlights it as an error because it has a different arity to clojure.core/filter-key.

It looks like Cursive is using the clojure.core function in its analysis, rather than the :use'd function. This manifests as an error, when its actually fine. The same behaviour happens if I :require and then :refer that function into the namespace.

[cursive-ide]

How is filter-key defined in Storm? Is it defined using some macro trickery?

[danielcompton]

Nope, just a plain function: https://github.com/apache/storm/blob/master/storm-core/src/clj/backtype/storm/util.clj#L307-L309

[cursive-ide]

Hmm, ok. Are you excluding filter-key using refer-clojure in the namespace you're :useing it from?

[danielcompton]

Nope

[cursive-ide]

So the problem with that is that you then have two functions with the same name bound in that namespace. One will overwrite the other, of course, but the order will depend on the details of how the ns macro is expanded. I'm assuming you also get a warning when loading that namespace about overwriting an existing var binding, right?

[danielcompton]

I would have expected it to, but it doesn't. I'm not familiar with Maven based Clojure projects so there could be something suppressing it? Isn't clojure.core always referred first in the ns macro though?

[danielcompton]

I fully agree that it's bad style not to :exclude it from :refer-clojure, but I would have thought Cursive would have clojure be bottom of the precedence list, and user code to be higher up?

[cursive-ide]

Oh yes, it's definitely a problem in Cursive - I'll fix that. It's odd that it didn't warn you, though.

[danielcompton]

I find it odd too...