<< Back to previous view

[TANAL-101] t.a.j fails to detect wrong tag on defn with destructured map arg Created: 31/Oct/14  Updated: 31/Oct/14  Resolved: 31/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: Not Reproducible Votes: 0
Labels: None


 Description   

Latest t.a.j calls the wrong-tag handler (if supplied) for these functions:

(defn avlf4 ^LinkedList [coll] (java.util.LinkedList. coll))
(defn avlf4b ^LinkedList [& coll] (java.util.LinkedList. coll))

but not for this one:

(defn avlf4c ^LinkedList [& {:keys [coll]}] (java.util.LinkedList. coll))


 Comments   
Comment by Andy Fingerhut [ 31/Oct/14 2:16 PM ]

Now that I think about it, I haven't checked whether the last case above would trigger CLJ-1232 behavior or not.

Comment by Andy Fingerhut [ 31/Oct/14 2:20 PM ]

I have now, and it does:

user=> (import '(java.util List))
java.util.List
user=> (defn ll1 ^List [] (java.util.LinkedList.))
#'user/ll1
user=> (.size (ll1))
0
user=> (defn ll2 ^List [& {:keys [coll]}] (java.util.LinkedList. coll))
#'user/ll2
user=> (ll2 :coll [4 5 -1])
(4 5 -1)
user=> (.size (ll2 :coll [4 5 -1]))
3
user=> (in-ns 'user2)
#<Namespace user2>
user2=> (clojure.core/refer 'user)
nil
user2=> (.size (ll1))

CompilerException java.lang.IllegalArgumentException: Unable to resolve classname: List, compiling:(/private/var/folders/v5/7hpqbpk51td3v351377gl6yw0000gn/T/form-init6319381494916415605.clj:1:1) 
user2=> (.size (ll2 :coll [4 5 -1]))

CompilerException java.lang.IllegalArgumentException: Unable to resolve classname: List, compiling:(/private/var/folders/v5/7hpqbpk51td3v351377gl6yw0000gn/T/form-init6319381494916415605.clj:1:1)
Comment by Nicola Mometto [ 31/Oct/14 2:25 PM ]

I've tried testing the last function with a dummy wrong-tag-handler that just prints a message when invoked and it looks like it is being invoked:

clojure.tools.analyzer.jvm> (do (analyze '(defn avlf4 ^LinkedList [& {:keys [coll]}] (java.util.LinkedList. coll))                                                                                                                
                                         (empty-env) {:passes-opts {:validate/wrong-tag-handler (ƒ [_ ast] (println "invoked"))}})                                                                                                
                                ∅)
invoked
invoked
invoked
invoked
∅
clojure.tools.analyzer.jvm>
Comment by Andy Fingerhut [ 31/Oct/14 6:51 PM ]

This is freaky weird, but in the latest Eastwood, which contains copies of the latest tools.analyzer and tools.analyzer.jvm, along with their dependencies, I can reproduce the bad behavior (no wrong-tag callbacks) by evaluating the same forms you did in your comment, except in the copied-and-renamed namespace eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm

I'm still trying to determine why this difference in behavior exists. It might be because of one of the libraries on which tools.analyzer.jvm not being identical between the Eastwood project version and what you depend upon in tools.analyzer.jvm's project.clj. I'll let you know if I find out.

Comment by Andy Fingerhut [ 31/Oct/14 6:53 PM ]

I can reproduce the bad behavior (no wrong-tag handler calls) by changing tools.analyzer.jvm's project.clj Clojure dependency to version 1.6.0 instead of 1.7.0-alpha3. Not sure why yet.

Comment by Nicola Mometto [ 31/Oct/14 7:01 PM ]

That makes sense, clojure 1.7.0-alpha3 has http://dev.clojure.org/jira/browse/CLJ-887 applied

Comment by Andy Fingerhut [ 31/Oct/14 7:06 PM ]

Got it. So CLJ-887 fix enables t.a.j and thus Eastwood to find more things to warn about than without that fix. Makes sense. Another example of how t.a.j is Clojure-IN-Clojure, and we depend upon the behavior of the latter Clojure.





[TANAL-100] Fix method matcher Created: 31/Oct/14  Updated: 31/Oct/14

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

Type: Defect Priority: Blocker
Reporter: Nicola Mometto Assignee: Nicola Mometto
Resolution: Unresolved Votes: 0
Labels: None


 Description   

places to fix:

jvm.utils/try-best-match
passes.jvm.annotate-methods
passes.jvm.validate/validate-call






[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  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: Declined 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.



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

it looks like tools.reader might have a bugged implementation of syntax-quote as it's losing the metadata.

Comment by Nicola Mometto [ 30/Oct/14 2:23 PM ]

I'm closing this since it's a tools.reader bug rather than a tools.analyzer one.
I still have not decided what's the best way to solve this and TBH I'm still investigating whether this might be a clojure bug or not.
In the meantime reverting https://github.com/clojure/tools.reader/commit/bb744f4e5513cea57d85638c83bc193a2390f9b9 should fix it

Comment by Andy Fingerhut [ 30/Oct/14 2:35 PM ]

Should I file a similar ticket for tools.reader ?

Comment by Nicola Mometto [ 30/Oct/14 2:38 PM ]

not necessary, I just pushed a fix

Comment by Andy Fingerhut [ 30/Oct/14 3:27 PM ]

In case there is a need to refer to this in the future, the fix went in with this commit, shortly after tools.reader 0.8.10 was released: https://github.com/clojure/tools.reader/commit/7812e704ceef683970ff2e28fd099bafefe4eba0





[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-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 Sat Nov 01 09:07:54 CDT 2014 using JIRA 4.4#649-r158309.