<< Back to previous view

[ASYNC-188] Properly pop `let` locals binding Created: 23/Feb/17  Updated: 23/Feb/17  Resolved: 23/Feb/17

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Attachments: Text File 0001-ASYNC-188-properly-pop-locals-binding.patch    

 Description   

ASYNC-187 incorrectly popped the locals stack, this patch fixes it



 Comments   
Comment by Alex Miller [ 23/Feb/17 12:56 PM ]

Applied for next release.





[ASYNC-187] Tag metadata is lost in local closed over by a loop Created: 23/Feb/17  Updated: 23/Feb/17  Resolved: 23/Feb/17

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Nicola Mometto Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: typehints

Attachments: Text File 0001-ASYNC-187-preserve-type-info-of-locals.patch    
Patch: Code
Approval: Ok

 Description   

This seems related to ASYNC-155, a small repro:

(defn foo []
  (a/go
    (let [^String a (identity "foo")]
      (loop []
        (.substring a 1 2)
        (a/<! nil)
        (recur)))))
Reflection warning, NO_SOURCE_PATH:23:17 - call to method substring can't be resolved (target class is unknown).

This bug affects all version of core.async, but it's getting triggered more now that the patch for ASYNC-138 applies a lexical transformation that makes code look like this, thus hitting this bug more often

Approach: The approach is the same used for ASYNC-155, applied to :let binding

Patch: 0001-ASYNC-187-preserve-type-info-of-locals.patch



 Comments   
Comment by Alex Miller [ 23/Feb/17 12:55 PM ]

Applied for next release.





[ASYNC-186] NPE when `go` closes over a local variable bound to nil Created: 23/Feb/17  Updated: 23/Feb/17  Resolved: 23/Feb/17

Status: Closed
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Nicola Mometto Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: regression

Attachments: Text File 0001-ASYNC-186-Apparently-Compiler.java-can-return-true-f.patch    
Patch: Code and Test
Approval: Ok

 Description   

This throws a NPE after ASYNC-138

(defn foo [x]
  (let [y nil]
    (a/go)))

Analysis: Compiler.java exhibits a quircky behaviour where for a local bound to nil, it'll return `true` for `lb.hasJavaClass()` but `lb.getJavaClass()` will return `nil`, which causes a NPE when we invoke `lb.getJavaClass().getName()`

user> (defmacro foo []
        (doseq [[l ^clojure.lang.Compiler$LocalBinding lb] &env]
          (println (.hasJavaClass lb) (.getJavaClass lb))))
#'user/foo
user> (let [a nil] (foo))
true nil

Approach:
Don't assume `.getJavaClass` will return non-nil when `hasJavaClass` returns true

Patch: 0001-ASYNC-186-Apparently-Compiler.java-can-return-true-f.patch



 Comments   
Comment by Alex Miller [ 23/Feb/17 9:11 AM ]

Applied for next build.





Generated at Sat Feb 25 03:13:58 CST 2017 using JIRA 4.4#649-r158309.