tools.analyzer

Reflection warnings from emitted forms, but type tags given on loop locals should prevent them?

Details

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

Description

I'm guessing at the common denominator here. I am using latest Eastwood and tools.analyzer(.jvm) on latest core.async library code. The first two reflection warnings are normal, from Eastwood's use of core.memoize and data.priority-map, I believe. It is the 5 in clojure.core.async.impl.channels that are the concern here. None of them appear in the output of 'lein check' for core.async

% lein eastwood '{:namespaces [ clojure.core.async.impl.channels ]}'
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.async.impl.channels ==
Reflection warning, clojure/core/async/impl/channels.clj:190:15 - reference to field lock can't be resolved.
Reflection warning, clojure/core/async/impl/channels.clj:192:17 - reference to field unlock can't be resolved.
Reflection warning, clojure/core/async/impl/channels.clj:65:56 - reference to field lock can't be resolved.
Reflection warning, clojure/core/async/impl/channels.clj:66:40 - reference to field lock can't be resolved.
Reflection warning, clojure/core/async/impl/channels.clj:70:36 - reference to field unlock can't be resolved.

Activity

Hide
Nicola Mometto added a comment -

The issue here was that validate-loop-locals was trying to be "smarter" than clojure, by validating non-primitive values too, making it possible for

(loop [x (Integer. 1)] (if (number? x) (recur "foo") (.hashCode x))

to compile (Clojure throws an exception at runtime for this code)

However it looks like this "enhancements" breaks the assumption of that piece of core.async code that loop args will be automatically tagged, so this has been reverted and we now match Clojure behaviour.
https://github.com/clojure/tools.analyzer.jvm/commit/8ff4ff8df01f5d0638030bc78fc7b8cad712d272

Show
Nicola Mometto added a comment - The issue here was that validate-loop-locals was trying to be "smarter" than clojure, by validating non-primitive values too, making it possible for
(loop [x (Integer. 1)] (if (number? x) (recur "foo") (.hashCode x))
to compile (Clojure throws an exception at runtime for this code) However it looks like this "enhancements" breaks the assumption of that piece of core.async code that loop args will be automatically tagged, so this has been reverted and we now match Clojure behaviour. https://github.com/clojure/tools.analyzer.jvm/commit/8ff4ff8df01f5d0638030bc78fc7b8cad712d272

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: