tools.analyzer

eval'ing emit-form result gives 2 reflection warnings that 'lein check' does not, for core.incubator namespace

Details

  • Type: Defect Defect
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Declined
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

With latest t.a(.jvm), Eastwood, and core.incubator, here is output I see:

% lein eastwood '{:namespaces [ clojure.core.incubator-test ]}'
Reflection warning, clojure/data/priority_map.clj:215:19 - call to equiv can't be resolved.
Reflection warning, clojure/core/memoize.clj:72:23 - reference to field cache can't be resolved.
== Eastwood 0.1.1-SNAPSHOT Clojure 1.5.1 JVM 1.7.0_15
== Linting clojure.core.incubator-test ==
Reflection warning, clojure/core/incubator.clj:90:7 - reference to field getClass can't be resolved.
Reflection warning, clojure/core/incubator.clj:90:7 - reference to field isArray can't be resolved.
Reflection warning, clojure/core/incubator_test.clj:17:39 - reference to field toString can't be resolved.
Reflection warning, clojure/core/incubator_test.clj:20:39 - reference to field toString can't be resolved.
Reflection warning, clojure/core/incubator_test.clj:21:39 - call to get can't be resolved.
Reflection warning, clojure/core/incubator_test.clj:21:39 - reference to field toString can't be resolved.
Reflection warning, clojure/core/incubator_test.clj:25:15 - reference to field toString can't be resolved.
Reflection warning, clojure/core/incubator_test.clj:31:15 - reference to field toString can't be resolved.
Reflection warning, clojure/core/incubator_test.clj:36:15 - reference to field toString can't be resolved.
Reflection warning, clojure/core/incubator_test.clj:37:15 - call to get can't be resolved.
Reflection warning, clojure/core/incubator_test.clj:37:15 - reference to field toString can't be resolved.
{:linter :unlimited-use,
 :msg
 "Unlimited use of (clojure.test clojure.core.incubator) in clojure.core.incubator-test",
 :line 11,
 :column 5}

== Warnings: 1 (not including reflection warnings)  Exceptions thrown: 0
Subprocess failed

Most of those reflection warnings also appear in the output of 'lein check' for that namespace, but 2 do not. They are:

Reflection warning, clojure/core/incubator_test.clj:21:39 - call to get can't be resolved.
Reflection warning, clojure/core/incubator_test.clj:37:15 - call to get can't be resolved.

Activity

Hide
Nicola Mometto added a comment -

This took me a lot to figure out.
It's not a tools.analyzer bug but a Clojure bug.

This will resolve the method at compile time:

(.method [..] ..)

This will not:

(.method ^{..} [..] ..)

In this case, lein check is not reporting any reflection warning because the only meta on [0] is :line/:column that gets stripped, while in eastwood [0] has :line/:column/:end-line/:end-column since it gets read by tools.reader.

Show
Nicola Mometto added a comment - This took me a lot to figure out. It's not a tools.analyzer bug but a Clojure bug. This will resolve the method at compile time:
(.method [..] ..)
This will not:
(.method ^{..} [..] ..)
In this case, lein check is not reporting any reflection warning because the only meta on [0] is :line/:column that gets stripped, while in eastwood [0] has :line/:column/:end-line/:end-column since it gets read by tools.reader.
Hide
Andy Fingerhut added a comment -

So to see if I understand correctly, ideally Clojure should resolve the method correctly even if there is metadata like in the (.method ^{..} [..] ..) case, as long as that metadata gives no :tag at all, or a correct :tag for the method resolved to?

Show
Andy Fingerhut added a comment - So to see if I understand correctly, ideally Clojure should resolve the method correctly even if there is metadata like in the (.method ^{..} [..] ..) case, as long as that metadata gives no :tag at all, or a correct :tag for the method resolved to?
Hide
Andy Fingerhut added a comment -

And if the answer to my question above is "yes", is it worth filing a ticket for the Clojure compiler, with any details you have learned about the source of the issue?

Show
Andy Fingerhut added a comment - And if the answer to my question above is "yes", is it worth filing a ticket for the Clojure compiler, with any details you have learned about the source of the issue?
Hide
Nicola Mometto added a comment -

Yes.
I'll definitely open a ticket for this once I fully grasp what's going on.

Looks like tools.analyzer/emitter is, even though in less cases (not in this for example), affected by a similar bug.

Show
Nicola Mometto added a comment - Yes. I'll definitely open a ticket for this once I fully grasp what's going on. Looks like tools.analyzer/emitter is, even though in less cases (not in this for example), affected by a similar bug.
Hide
Nicola Mometto added a comment -

Should be fixed for tools.analyzer, here's the ticket for clojure http://dev.clojure.org/jira/browse/CLJ-1326

Show
Nicola Mometto added a comment - Should be fixed for tools.analyzer, here's the ticket for clojure http://dev.clojure.org/jira/browse/CLJ-1326

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: