<< Back to previous view

[TANAL-98] Exception thrown for an extend-protocol form Created: 30/Oct/14  Updated: 30/Oct/14  Resolved: 30/Oct/14

Status: Closed
Project: tools.analyzer
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Andy Fingerhut Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: None


 Description   

Steps to reproduce:

pull latest master of Eastwood, which now includes latest master of t.a(.jvm) as of this ticket being created.

% cd crucible
% ./clone.sh  (skip if already pulled crucible repos)
% cd repos/cassaforte-2014-03-11

% lein eastwood '{:namespaces [clojurewerkz.cassaforte.conversion]}'
objc[5290]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/java and /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
== Eastwood 0.1.5-SNAPSHOT Clojure 1.5.1 JVM 1.7.0_45
== Linting clojurewerkz.cassaforte.conversion ==
Reflection warning, clojurewerkz/cassaforte/bytes.clj:56:3 - call to deserialize can't be resolved.
Exception thrown during phase :analyze+eval of linting namespace clojurewerkz.cassaforte.conversion
IllegalArgumentException No implementation of method: :typename of protocol: #'clojure.reflect/TypeReference found for class: nil
	clojure.core/-cache-protocol-fn (core_deftype.clj:541)
	clojure.reflect/fn--9008/G--9003--9013 (reflect.clj:48)
	clojure.reflect.JavaReflector (java.clj:169)
	clojure.reflect/fn--8990/G--8986--8993 (reflect.clj:44)
	clojure.reflect/fn--8990/G--8985--8997 (reflect.clj:44)
	clojure.core/apply (core.clj:619)
	clojure.core/partial/fn--4190 (core.clj:2396)
	clojure.reflect/type-reflect (reflect.clj:100)
	clojure.core/apply (core.clj:623)
	eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/type-reflect (utils.clj:22)
	eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/members* (utils.clj:246)
	clojure.core/apply (core.clj:617)

[... most lines of stack trace omitted ...]

The following form was being processed during the exception:
(extend-protocol
 DefinitionToMap
 ResultSet
 (to-map
  [input]
  (into [] (for [row input] (into {} (for [cd #] (let # #))))))
 Host
 (to-map
  [host]
  {:datacenter (.getDatacenter host),
   :address (.getHostAddress (.getAddress host)),
   :rack (.getRack host)}))

[... more lines omitted ...]


 Comments   
Comment by Nicola Mometto [ 30/Oct/14 12:04 PM ]

Fixed:
https://github.com/clojure/tools.analyzer.jvm/commit/50c5d8dc83ae0254695ffd1dd86e84f64addc2b7
https://github.com/clojure/tools.analyzer.jvm/commit/4e40ae890633c0220b3401f91eb07606099955e0





[TANAL-99] Many new reflection warnings analyzing core.rrb-vector in latest t.a(.jvm) vs. 0.6.1 Created: 30/Oct/14  Updated: 30/Oct/14

Status: Open
Project: tools.analyzer
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Andy Fingerhut Assignee: Nicola Mometto
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Steps to reproduce:
pull latest Eastwood master

% cd crucible
% ./clone.sh  (skip if already pulled crucible repos)
% cd repos/core.rrb-vector-2014-02-14

% lein check
(no reflection warnings)
% lein eastwood '{:debug #{:compare-forms}}'
(many reflection warnings)

The forms emitted by t.a(.jvm) version 0.6.1 did not cause Clojure 1.6.0 to produce these reflection warnings.

The :compare-forms debug option to Eastwood will cause forms-read.txt and forms-emitted.txt files to be written, where the latter may be helpful in determining what it is about the emitted forms that are causing Clojure to reflection-warn about them. Sorry I haven't tracked this further yet.






[TANAL-97] analyze+eval throws exception with Clojure 1.7.0-alpha3 but not 1.6.0 for project utf8 Created: 28/Oct/14  Updated: 28/Oct/14  Resolved: 28/Oct/14

Status: Closed
Project: tools.analyzer
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Andy Fingerhut Assignee: Nicola Mometto
Resolution: Declined Votes: 0
Labels: None


 Description   

I haven't tracked down what is going on here. I am using tools.analyzer(.jvm) 0.6.1 with the latest Eastwood where I've noticed this (but also saw it with the 0.2.x version of tools.analyzer(.jvm) used by Eastwood 0.1.4). I haven't yet checked whether the latest released tools.analyzer(.jvm) improves on this behavior.

This might also be a bug introduced in Clojure 1.7.0-alpha3 vs. 1.6.0.

To see the issue, get latest Eastwood, pull all of the crucible projects, or at least the one that gets renamed utf8-2013-11-15, and run these two commands after doing 'mvm install' on the latest Clojure master as of 1.7.0-alpha3. The last command below will use 1.7.0-master-SNAPSHOT of Clojure, so it needs to be installed in your ~/.m2 named as that, or change the project.clj file to name 1.7.0-alpha3 instead.

% lein clean
% lein with-profile +1.6 eastwood
% lein clean
% leon with-profile +1.7 eastwood

With the last command I see an exception like this:

Exception thrown during phase :analyze+eval of linting namespace pjstadig.utf8
Got exception with extra ex-data:
    msg='Could not resolve var: Charset'
    (keys dat)=(:end-line :line :column :end-column :file :var)
ExceptionInfo Could not resolve var: Charset
	clojure.core/ex-info (core.clj:4566)
	eastwood.copieddeps.dep2.clojure.tools.analyzer.passes.jvm.validate/eval1973/fn--1975 (validate.clj:29)
	clojure.lang.MultiFn.invoke (MultiFn.java:229)


 Comments   
Comment by Nicola Mometto [ 28/Oct/14 12:03 PM ]

This appears to be caused because clojure 1.7.0-alpha3 fails to compile nio.core, thus the ns expression is not evaluated.

This is a regression introduced with clojure 1.7.0-alpha2, I'm investigating the cause and will open a CLJ ticket

Comment by Nicola Mometto [ 28/Oct/14 12:14 PM ]

turns out it's not even a clojure reggression, it's a bug in the last released version of nio that has been fixed in the SNAPSHOT version: https://github.com/pjstadig/nio/issues/4

clojure <=1.7.0-alpha2 silently ignored this bug but commit https://github.com/clojure/clojure/commit/85169b785c5dd59e89c0bd12600eebe5f6172874 had the side effect of exposing the bug

Comment by Andy Fingerhut [ 28/Oct/14 2:24 PM ]

Thanks for tracking that down! (inc Bronsa)

Comment by Andy Fingerhut [ 28/Oct/14 5:18 PM ]

And this helped me discover that although I tried to stop Eastwood's linking at the point that analyze+eval returns an AST indicating that eval threw an exception, I was only checking the top-level AST. I should have been checking all sub-ASTs of top-level do forms, and do forms nested inside those, etc. Soon Eastwood will stop earlier, closer to the real problem in this case.





Generated at Thu Oct 30 12:09:14 CDT 2014 using JIRA 4.4#649-r158309.