Use qualified class names for return type hints of standard Clojure functions


tools.analyzer (used by the Clojure lint tool Eastwood) crashes when encountering such a simple-named return type hint. So currently, I cannot lint parts of my project because there's code that calls `clojure.core/format`.

Cause: return type class names are not fully qualified in clojure.core.

Solution: The attached patch converts all function return type hints to spell out the class name fully qualified.

Patch: 0001-Use-fully-qualified-class-names-for-return-type-hint.patch




Tassilo Horn
August 29, 2014, 5:29 AM

@Alex: 1. is not as weird as it sounds at first. For example, consider you have macros that generate complete APIs for something into some new namespace. Then it can make sense to use a real vanilla namespace, i.e., without referring clojure.core and importing java.lang. With 2. I side with Nicola and consider CLJ-1232 a bug.

@Nicola: Today I've used Eastwood (0.1.4) to lint my project. It crashed when it encountered this definition:

The message was:

So it seems it crashes because `format` has a `^String` return type hint. The namespace containing the `errorf` macro above has no modified ns-imports, i.e., all java.lang classes are imported there, too.

Nicola Mometto
August 29, 2014, 5:46 AM

Tassilo, since `errorf` is a macro, that error is probably caused at the expansion point of that macro in a namespace that unmaps 'String.
If that's not the case, please open a ticket in the eastwood repo

Tassilo Horn
August 29, 2014, 6:16 AM

Nicola, you are correct. As I've explained above to Alex, I generate APIs in fresh namespaces that don't refer clojure.core and also ns-unmap all java.lang classes, and the generated code also contains `errorf`-forms.

Well, since `ns-unmap` is there, I think it's legit to use it. So that makes CLJ-1232 even more important. But until that gets fixed which requires a common agreement that it is indeed a bug, I'd be very happy if this patch could be accepted. I mean, when it cannot do any harm and doesn't obscure anything but helps at least one person, then why not do it?

Alex Miller
December 15, 2015, 8:21 AM

Updated to simplify this ticket now that CLJ-1232 is closed.

As written, the ticket looks like it is a problem with tools.analyzer rather than with Clojure. Is this ticket still accurate wrt latest Clojure and tools.analyzer?

If so, please give a reproducible example in the description.

Alex Miller
December 15, 2015, 9:52 AM

Closed per Nicola.

Not Reproducible




Tassilo Horn






Affects versions