<< Back to previous view

[CTYP-234] Setting :collect-only attribute for a namespace does not collect type aliases Created: 23/Jun/15  Updated: 21/Jul/15  Resolved: 21/Jul/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.8, 0.3.x

Type: Defect Priority: Blocker
Reporter: Gordon Syme Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None
Environment:

Tested with 0.3.0-alpha5


Attachments: Text File ctyp-234.patch    
Patch: Code and Test

 Description   

Problem

Adding the {:core.typed {:collect-only true}} attribute to a namespace prevents core.typed from collecting any type aliases defined via defalias in that namespace.

E.g.

(ns collect-only-bug.other
  {:core.typed {:collect-only true}}
  (:require [clojure.core.typed :as t]))

(t/defalias MyType (t/HMap :mandatory {:foo String
                                       :bar t/AnyInteger}))
(ns collect-only-bug.core
  (:require [clojure.core.typed :as t]
            [collect-only-bug.other :as other]))

(t/ann foo [other/MyType -> t/AnyInteger])
(defn foo
  [x]
  (:bar x))
user=> (t/check-ns 'collect-only-bug.core)
Start collecting collect-only-bug.core
Finished collecting collect-only-bug.core
Collected 1 namespaces in 218.520311 msecs
Not checking clojure.core.typed (does not depend on clojure.core.typed)
Not checking collect-only-bug.other (tagged :collect-only in ns metadata)
Start checking collect-only-bug.core
Type Error (collect_only_bug/core.clj:8:9) Internal Error (collect_only_bug/core.clj:8:3) Cannot resolve name collect-only-bug.other/MyType

ExceptionInfo Type Checker: Found 1 error  clojure.core/ex-info (core.clj:4403)

Solution

Add a new predicate should-collect-ns? and use it in collect-phase
to pick namespaces to collect.

Pull request: 33
Patch: ctyp-234.patch (some trailing whitespace)
Commit: 773291
Release: 0.3.8



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 24/Jun/15 8:16 AM ]

Started work here: https://github.com/typedclojure/core.typed/pull/10





[CTYP-80] Issue with filter subtyping/simplification Created: 02/Oct/13  Updated: 20/Jul/15  Resolved: 20/Jul/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.8, 0.3.x

Type: Defect Priority: Major
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ctyp-80-fix.patch    

 Description   

This code apparently broke around 0.2.11. It's unclear what the issue was,
but it seems it was fixed sometime before 0.3.7.

http://paste2.org/kWVNZxC7

Code review: CTYP-80
Patch: ctyp-80-fix.patch
Commit: e21ece3
Release: 0.3.8






[CTYP-212] Can't create a promise of the same type as a record field Created: 20/Apr/15  Updated: 21/Jul/15  Resolved: 21/Jul/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.8, 0.3.x

Type: Defect Priority: Major
Reporter: Timo Mihaljov Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None
Environment:

[org.clojure/core.typed "0.2.84"]
[org.clojure/clojure "1.6.0"]


Attachments: Text File ctyp-212.patch    
Patch: Code and Test

 Description   

Problem

It seems to be impossible to create a promise of the same type as a record field:

(ns cttest.core
  (:require [clojure.core.typed :as t]))

(t/ann-record MyRecord [p :- (t/Promise int)])

(defrecord MyRecord [p])

(defn foo []
  (t/let [x :- (t/Promise int) (promise)]))

; Type Error (cttest/core.clj:9:32) Polymorphic function promise could not be applied to arguments:
; Polymorphic Variables:
;         x
;
; Domains:
;
;
; Arguments:
;
;
; Ranges:
;         (t/Promise x)
;
; with expected type:
;         (t/Promise int)
;
; in: (promise)
; in: (promise)

Changing the type of p in MyRecord to any other type, say (t/Promise String) makes foo pass the type checker.

Solution

This seems to have been fixed sometime between 0.2.84 and 0.3.7. Adding a
passing unit test to close this issue.

Pull request: 30
Patch: ctyp-212.patch
Commit: 2c00a3f
Release: 0.3.8



 Comments   
Comment by Timo Mihaljov [ 20/Apr/15 11:36 PM ]

I hit the save button too soon. I couldn't reproduce this in a clean project, so there's something else going on in my project that's causing this. I might reopen the issue once I've narrowed down what's causing it.

Comment by Timo Mihaljov [ 22/Apr/15 12:39 AM ]

The difference was that the test project was missing the record. I've reopened the issue now that it's reproducible.





[CTYP-203] Unreproducable internal error Created: 09/Mar/15  Updated: 21/Jul/15  Resolved: 21/Jul/15

Status: Resolved
Project: core.typed
Component/s: Core type system
Affects Version/s: None
Fix Version/s: 0.3.8, 0.3.x

Type: Defect Priority: Major
Reporter: Colin Yates Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None
Environment:

osx yosemite, jdk 7


Attachments: Text File ctyp-203.patch    
Patch: Code and Test

 Description   

Problem

It is unclear how to reproduce, but this is the original report.

The following REPL shows the problem:

(t/defalias BaseValidationSchema
            '[java.lang.Boolean (t/HMap :complete? false)])

=> nil
(t/cf [true {}] BaseValidationSchema)
Type Error (NO_SOURCE_FILE) Internal Error (:<NO LINE>) Wrong number of arguments passed to type function. Expected 1, actual 2: clojure.core.typed/Vec [java.lang.Boolean (clojure.core.typed/HMap :mandatory {})]
ExceptionInfo Type Checker: Found 1 error  clojure.core/ex-info (core.clj:4403)
(t/cf [true {}] '[java.lang.Boolean (t/HMap :complete? false)])
=> [(t/HVec [true (t/HMap :complete? true)]) {:then tt, :else ff}]

From https://groups.google.com/d/msg/clojure-core-typed/uX2v9wbwTwI/yyErih2cPDMJ

Solution

Add passing unit test since we cannot reproduce.

Pull request: 34
Patch: ctyp-203.patch
Commit: 372108
Release: 0.3.8






[CTYP-54] Merge compatible types to make more accurate ones Created: 11/Sep/13  Updated: 22/Jul/15  Resolved: 22/Jul/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Declined Votes: 0
Labels: None


 Description   

We need to figure out how to merge types like (I (Vec Any) (Seqable Number)). A general solution is probably needed: we want a way for new types to "plug in" to this behaviour.

This needs to be considered in Clojurescript too, where Vec and Seqable are implemented as protocols and do not have an inheritance relationship.

(From https://gist.github.com/pnf/e208b0d44860aedc9c9d)

;; There seems to be some difficulty in merging the two assertions here.
(t/ann testassert6 [(t/Vec Any) -> (t/Vec t/AnyInteger)])
(defn testassert6 [m]
(assert (vector? m)) ; this should be redundant
(assert (every? integer? m))
m)
;; Type Error (imdb.testassert:92) Local binding m expected type (t/Vec t/AnyInteger), but actual type (I (IPersistentVector Any) (t/Coll t/AnyInteger))
;; in: m
;; Type Error (imdb.testassert:92) Type mismatch:
;; Expected: (t/Vec t/AnyInteger)
;; Actual: (I (IPersistentVector Any) (t/Coll t/AnyInteger))
;; in: (do (if (clojure.core/vector? m) nil (throw (new java.lang.AssertionError #))) (if (clojure.core/every? clojure.core/integer? m) nil (throw (new java.lang.AssertionError #))) m)
;; Type Error (imdb.testassert:92:1) Type mismatch:
;; Expected: (Fn [(t/Vec Any) -> (t/Vec t/AnyInteger)])
;; Actual: (Fn [(t/Vec Any) -> (I (IPersistentVector Any) (t/Coll t/AnyInteger)) :filters {:then (& (is (IPersistentVector Any) 0) (! (U nil false) 0)), :else (is (U nil false) 0)} :object {:id 0}])
;; in: (def testassert6 (fn* ([m] (do # # m))))



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 22/Jul/15 2:17 AM ]

This hasn't been an issue in practice, declined.





[CTYP-263] Unnecessary type hint required in catch expression Created: 27/Jul/15  Updated: 02/Aug/15  Resolved: 02/Aug/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: 0.3.9
Fix Version/s: 0.3.10, 0.3.x

Type: Defect Priority: Major
Reporter: Mark Feeney Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: regression


 Description   

Problem

Below is a case where core.typed requires a type hint that Clojure itself doesn't.
(Clojure 1.7, core.typed 0.3.9)

user=> *warn-on-reflection*
true

user=> (try :anything (catch Exception e (.getCause e)))
:anything

user=> (t/cf (try :anything (catch Exception e (.getCause e))))
Type Error (/tmp/form-init1733185424844917450.clj:1:41) Unresolved host interop: getCause

Target java.lang.Exception has no member getCause

Hint: use *warn-on-reflection* to identify reflective calls
in: (. e getCause)

ExceptionInfo Type Checker: Found 1 error  clojure.core/ex-info (core.clj:4593)

Adding a hint satisfies core.typed, but is unnecessary for plain Clojure.

user=> (t/cf (try :anything (catch Exception e (.getCause ^Exception e))))
(t/U (t/Val :anything) nil Throwable)

This used to work without the hint. It first started failing here: (git bisect)

be52bc50cb9f5fd7947d744c5045315ecb0561f1 is the first bad commit
commit be52bc50cb9f5fd7947d744c5045315ecb0561f1
Author: Ambrose Bonnaire-Sergeant <...@gmail.com>
Date:   Wed Jul 1 14:14:13 2015 +0800

    Upgrade tools.analyzer.jvm from 0.4.0 to 0.6.7.

Notes

Discussion: https://groups.google.com/forum/#!topic/clojure-core-typed/EJIl01yQhPk

tools.analyzer issue: http://dev.clojure.org/jira/browse/TANAL-112
(already fixed in 0.6.8-SNAPSHOT, see thread)

Solution

Bump t.a.j dep to include 966fe1f and add test.

Pull request: 50
Commits:






[CTYP-247] Function bodies should rewrite themselves if possible Created: 19/Jul/15  Updated: 02/Aug/15  Resolved: 02/Aug/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.10, 0.3.x

Type: Defect Priority: Major
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Problem

core.typed resolves some reflective Java interop manually if the
Clojure compiler cannot.

(fn [a :- java.io.File] (.getParent a))

However, in some cases, *warn-on-reflection* still says reflection exists.

This especially happens inside function bodies.

The cause is probably mishandled rewriting of composite AST nodes like :fn
or :do which then drops the rewriting on the floor.

Next steps

Minimal failing case.

Pull request: 49
Commits: Fix+test 488c927






[CTYP-291] ClassNotFoundException clojure.core.cache.CacheProtocol Created: 10/Nov/15  Updated: 11/Nov/15  Resolved: 11/Nov/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: 0.3.15, 0.3.16
Fix Version/s: 0.3.17

Type: Defect Priority: Major
Reporter: Nathan Sorenson Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: bug
Environment:

OSX 10.11.1, Clojure 1.7.0


Attachments: Text File lein-conflicts.txt     Text File trace1.txt    

 Description   

Problem

On a fresh "lein new" project with only clojure 1.7.0 and core.typed 0.3.15, (t/check-ns) fails with:

ClassNotFoundException clojure.core.cache.CacheProtocol  java.net.URLClassLoader$1.run (URLClassLoader.java:372)

Solution

This commit generates jars that contains AOT compiled code only for core.typed namespaces, but not for 3rd party libraries (like core.cache). This is because these lines trim out all .class files that are not under core.typed due to problems with CLJS.

We disable AOT compilation completely to work around this issue. We could instead selectively remove CLJS files, we should investigate if this is possible later.

Pull request: 79
Commit: 8aa2df2



 Comments   
Comment by Nathan Sorenson [ 10/Nov/15 5:51 PM ]

Forgot to add: Java version 1.8.0_25-b02

Comment by Ambrose Bonnaire-Sergeant [ 11/Nov/15 10:11 AM ]

I'm pretty sure this is because the current build deletes 3rd party AOT class files, while leaving the core.typed class files intact.

Workaround: [org.clojure/core.typed "0.3.15" :classifier "slim"]





[CTYP-296] Overlap of free variables and other types should not be empty Created: 17/Nov/15  Updated: 17/Nov/15  Resolved: 17/Nov/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.19

Type: Defect Priority: Major
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Problem

Intersections containing type variables and values like

(I a (Val :a))

are being simplified to

(U)

We cannot predict what a type variable overlaps with (well, technically we could use its type bounds, but let's be more conservative for now), so this intersection should be left unchanged.

Solution

Overlap is the culprit. Ensure there is always an overlap between type variables and other types.

Pull request: 82
Commit: c1cfba87






[CTYP-305] t/cast does not run under rewriting type checking Created: 28/Jan/16  Updated: 29/Jan/16  Resolved: 29/Jan/16

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: 0.3.19
Fix Version/s: 0.3.20

Type: Defect Priority: Major
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Problem

The AST rewriting algorithm deletes the contract check for casts.

(cf (cast Int nil))
;=> Int

This passes static type checking, but does not run the code.

Solution

This happens because a t/cast expression is always rewritten to return `nil`. The AST rewriting algorithm should be fixed to preserve the original contract check.

Pull request: 92
Commit: a05205be
Version: 0.3.20






[CTYP-284] Remove redundant checking in typed load Created: 27/Oct/15  Updated: 30/Jan/16  Resolved: 30/Jan/16

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: 0.3.14
Fix Version/s: 0.3.20

Type: Enhancement Priority: Major
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Problem

When using typed load and `clojure.core/load` is correctly monkey patched, typed dependencies are
redundantly checked via:
1. Normal `check-ns`-style dependency checking, then
2. Evaluating `load` as part of evaluating a `ns` form triggers another typed load for the same namespace.

Solution

We assume if typed load is being used, then `load` is correctly monkey patched.

We add an extra var that indicates if we are currently in a typed load, which disables the first
situation (`check-ns`-style checking).

Pull request: 73
Commit: e7ec01
Version: 0.3.20






[CTYP-216] PermGen memory leak when type checking with faulty types Created: 16/May/15  Updated: 31/Jan/16  Resolved: 31/Jan/16

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Olli Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None
Environment:
  • OSX 10.10
  • Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
  • Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
  • Clojure 1.6.0


 Description   

This is not the only instance where I ran into the java.lang.OutOfMemoryError, but the following is a rather minimal case that reproduced the problem for me consistently before I upgraded my JVM options to use higher MaxPermSize (was using the default Leiningen settings before).

https://gist.github.com/luxbock/bd54c9e519527cdf855a



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 21/Jun/15 8:51 AM ]

Since Java 8 removed the concept of perm gen space, does it help to upgrade to Java 8?

Comment by Ambrose Bonnaire-Sergeant [ 31/Jan/16 7:02 PM ]

I'm closing this as core.typed supports Java 8 as minimum now, which removed permanent generation.





[CTYP-229] Checker slows development in rechecking dependent namespaces Created: 21/Jun/15  Updated: 31/Jan/16  Resolved: 31/Jan/16

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Mahmood Ali Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

`check-ns` is quite aggressive in checking the dependencies of the namespaces explicitly passed in, somewhat unexpectedly. This significantly slows down development when attempting to type-check a namespace with large number of dependencies. Is there an option to type-check a namespace without its transitive dependencies?

Also, I noticed that `check-ns-and-deps` could be using an incorrect criteria for checking dependencies. My local patch is the following: https://github.com/clojure/core.typed/commit/78937733f7db750e94b1a142f3c64fa37bc7a255 . Not sure how to write a test for it though.



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 22/Jun/15 12:47 AM ]

The current behaviour is intentional, with the intention that `check-ns` is ruthlessly immune to REPL state.

Selectively ignoring dependencies is perhaps not desirable feature. It would certainly speed up REPL development because it skips a lot of static type checking.

I think what we really want is what `clojure.core/load` does for transitive dependencies: only check them once in the same session. This way, it speeds up REPL development. One off type checks still need to check everything though.

Comment by Ambrose Bonnaire-Sergeant [ 22/Jun/15 10:24 AM ]

Prototype of `check-ns` that caches its transitive dependencies is at `0.3.0-20150622.124924-21`.

`check-ns` now takes a keyword arg `:clean` that acts like the old `check-ns`.

Comment by Ambrose Bonnaire-Sergeant [ 31/Jan/16 7:03 PM ]

Closing because typed load is now the preferred way to check namespaces, which only checks as much as `require` compiles.

See http://dev.clojure.org/jira/browse/CTYP-284





[CTYP-313] subtyping optional keywords in HMaps Created: 13/Apr/16  Updated: 15/Apr/16  Resolved: 15/Apr/16

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: 0.3.22
Fix Version/s: 0.3.23

Type: Defect Priority: Major
Reporter: Claire Alvis Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

I would expect all of these functions to be well typed, but I get an error only in the type of z-getter:

(ns test.core
  (:require [clojure.core.typed :as t]))

(t/defalias XYZMap
  (t/TFn [[x :variance :covariant :< Number]
          [y :variance :covariant :< Number]
          [z :variance :covariant :< Number]]
         (t/HMap :complete? true
                 :mandatory {:x x
                             :y (t/Option y)}
                 :optional {:z z})))

(t/defn x-getter
  [m :- (XYZMap Integer Integer Integer)] :- Integer
  (:x m))

(t/defn y-getter
  [m :- (XYZMap Integer Integer Integer)] :- (t/Option Integer)
  (:y m))

(t/defn z-getter
  [m :- (XYZMap Integer Integer Integer)] :- (t/Option Integer)
  (:z m))


Type Error (test/core.clj:23:3) Type mismatch:

Expected: 	(t/Option Integer)

Actual: 	(t/U z nil)
in: (:z m)

ExceptionInfo Type Checker: Found 1 error  clojure.core/ex-info (core.clj:4593)

Solution

Type variables in optional HMap entries are not being substituted.

Pull request: 100
Commit: a62877
Version: 0.3.23






[CTYP-93] Support refinement types Created: 08/Nov/13  Updated: 20/Jul/15  Resolved: 20/Jul/15

Status: Resolved
Project: core.typed
Component/s: Core type system
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Declined Votes: 1
Labels: None


 Description   

Typed Racket's refinement types are useful. We should implement something similar.



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 20/Jul/15 11:17 PM ]

This really went nowhere - the issues with purity around refinement types are pretty odd (basically two invocations of a refined predicate must evaluate to the same value, ie. be pure functions, because they have the same object) and probably not something we want.

Looking to the future, perhaps we want upcoming newtype in Typed Racket.

Futher discussion:





[CTYP-27] clojure.lang.RT/nth's type doesn't currently allow nil as the first argument Created: 23/Jul/13  Updated: 21/Jul/15  Resolved: 21/Jul/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.8, 0.3.x

Type: Defect Priority: Minor
Reporter: Alan Busby Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ctyp-27.patch    
Patch: Code and Test

 Description   

Problem

The destructuring of (let [[x] [1 2 3]] x) is type checked differently to
(first [1 2 3]), the former being a type error.

Solution

Already fixed sometime around 0.1.18, but adding tests to prove this works.

Notes

Re: Why (first [1 2 3]) isn't equivalent to (let [[x & xs] [1 2 3]] x)
"
; This is because clojure.lang.RT/nth's type doesn't currently allow nil as
; the first argument. Should be fixed in master, but please submit a bug report to
; JIRA, it might not be completely correct.
; -Ambrose"

From
https://github.com/frenchy64/type-examples/blob/master/src/type_examples/core.clj

I'm not sure if this is fixed in master, but I couldn't build the current 0.1.18-SNAPSHOT (master) to check.

Pull request: CTYP-27
Patch: ctyp-27.patch
Commit: f4c699d
Release: 0.3.8



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 23/Jul/13 6:09 AM ]

Sorry, master is a bit broken at the moment. It may take a week to get it stable actually!

Comment by Ambrose Bonnaire-Sergeant [ 27/Jul/13 9:41 AM ]

This needs a special case for invoke-nth, to handle things like (nth (I (Seqable x) (CountRange 1)) 0).





[CTYP-168] Support metadata map and :arglists in clojure.core.typed/defn Created: 12/Aug/14  Updated: 21/Jul/15  Resolved: 21/Jul/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.8, 0.3.x

Type: Enhancement Priority: Minor
Reporter: Tobias Kortkamp Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 1
Labels: None

Attachments: Text File 0001-Add-arglists-metadata-to-vars-defined-using-defn.patch     Text File 0002-Add-arglists-metadata-to-vars-defined-using-defn.patch     Text File 0003-Add-arglists-and-attr-map-support-to-defn.patch     Text File ctyp-168.patch    
Patch: Code and Test

 Description   

Minimal example:

(clojure.core/defn f [])
(meta #'f)
;; => {:arglists ([]), ...}

(clojure.core.typed/defn g [])
(meta #'g)
;; => :arglists key missing completely

This is problematic, because g's arguments won't show up in its documentation via e.g. clojure.repl/doc
and I think lots of other tools assume that :arglists is there.

I've attached a patch that should fix this (and have also just signed Clojure's CA).

Pull request: 32
Patch: ctyp-168.patch (deleted a trailing whitespace)
Commit: 73d6be1
Release: 0.3.8



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 12/Aug/14 11:41 AM ]

Is your name on this list? http://clojure.org/contributing

Comment by Ambrose Bonnaire-Sergeant [ 12/Aug/14 11:41 AM ]

Oh I see you just signed it. Let me know when your name pops up and I'll merge this. Thanks!

Comment by Ambrose Bonnaire-Sergeant [ 12/Aug/14 11:43 AM ]

I get some errors in the unit tests. Can you run `mvn test` and fix them please?

Comment by Tobias Kortkamp [ 12/Aug/14 12:15 PM ]

Found the problem and attached a new patch.
The tests pass now..

Comment by Tobias Kortkamp [ 12/Aug/14 11:14 PM ]

I've attached an updated version of the patch that additionally adds attr-map support to defn. The tests still pass and it looks like my name appears on the contributors list now.

Comment by James Reeves [ 04/Jan/15 8:47 PM ]

This would be useful to fix, otherwise docs aren't generated properly when using clojure.core.typed/defn.





[CTYP-172] ExactCount should work with destructuring Created: 25/Aug/14  Updated: 22/Jul/15  Resolved: 22/Jul/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.9, 0.3.x

Type: Enhancement Priority: Minor
Reporter: Tamir Duberstein Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ctyp-172.patch    
Patch: Code and Test

 Description   

Problem

ExactCount does not work with destructuring.

learning.core=> (cf (fn [[a b] :- (I (Vec Num) (ExactCount 2))] [(+ a b)]))
Type Error (/private/var/folders/34/98dbvkhn7v1clfvl5_y_fkc00001j3/T/form-init2527243481617671751.clj) Static method clojure.lang.Numbers/add could not be applied to arguments:


Domains:
	java.lang.Long java.lang.Long
	java.lang.Double java.lang.Double
	AnyInteger AnyInteger
	java.lang.Number java.lang.Number

Arguments:
	(U nil Number) (U nil Number)

Ranges:
	java.lang.Long
	java.lang.Double
	AnyInteger
	java.lang.Number

in: (clojure.lang.Numbers/add a b)
in: [(clojure.lang.Numbers/add a b)]



ExceptionInfo Type Checker: Found 1 error  clojure.core/ex-info (core.clj:4403)

Solution

This was fixed sometime before 0.3.8. Adding passing test to close this issue.

Pull request: 35
Patch: ctyp-172.patch
Commit: fb17b8
Release: 0.3.9






[CTYP-210] (long AnyInteger) doesn't typecheck Created: 08/Apr/15  Updated: 22/Jul/15  Resolved: 22/Jul/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.9, 0.3.x

Type: Defect Priority: Minor
Reporter: Timo Mihaljov Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None
Environment:

[org.clojure/core.typed "0.2.84"]
[org.clojure/clojure "1.6.0"]


Attachments: Text File ctyp-210.patch    

 Description   
reiska.core=> (t/cf (long (+ 2 (int 123))))
Type Error (/private/var/folders/x2/47j5hlbs01b9b4mjz_8fyf05m8hy4p/T/form-init7340610759194794514.clj:1:7) Static method clojure.lang.RT/longCast could not be applied to arguments:


Domains:
        long

Arguments:
        t/AnyInteger

Ranges:
        long

in: (clojure.lang.RT/longCast (clojure.lang.Numbers/add 2 (clojure.lang.RT/intCast 123)))
in: (clojure.lang.RT/longCast (clojure.lang.Numbers/add 2 (clojure.lang.RT/intCast 123)))


ExceptionInfo Type Checker: Found 1 error  clojure.core/ex-info (core.clj:4403)

Pull request: 36
Patch: ctyp-210.patch
Commit: 68d20b
Release: 0.3.9



 Comments   
Comment by Timo Mihaljov [ 14/Apr/15 10:57 PM ]

Here's what I think is going on:

1. clojure.core/long is defined as an inlineable function, so its body gets inlined and core.typed never sees the function application (long x) (where long's type is [t/Any -> Long]). Instead, it sees the method application (clojure.lang.RT/longCast x) and has to infer the method's type from its Java type.

This hypothesis is supported by the following experiment. Commenting out the inline form in a copy of clojure.core/long makes it apply cleanly to t/AnyInteger values.

;;; Doesn't typecheck

(t/ann ^:no-check my-long [t/Any -> long])
(defn my-long
  {:inline (fn [x] `(. clojure.lang.RT (longCast ~x)))}
  [^Number x]
  (clojure.lang.RT/longCast x))

(def a (my-long (t/ann-form 123 t/AnyInteger)))
;;; Typechecks

(t/ann ^:no-check my-long2 [t/Any -> long])
(defn my-long2
  ; Commented out: {:inline (fn [x] `(. clojure.lang.RT (longCast ~x)))}
  [^Number x]
  (clojure.lang.RT/longCast x))

(def b (my-long2 (t/ann-form 123 t/AnyInteger)))

2. The clojure.lang.RT/longCast method is overloaded. It seems that instead of inferring a multi-arity type, core.typed seems to pick just one of the arities. In this case it picks the wrong arity: t/AnyInteger is a valid argument to longCast(Object x), but not the picked longCast(long x).





[CTYP-257] Empty intersection should be Top, not Bottom Created: 23/Jul/15  Updated: 23/Jul/15  Resolved: 23/Jul/15

Status: Resolved
Project: core.typed
Component/s: Core type system
Affects Version/s: None
Fix Version/s: 0.3.9, 0.3.x

Type: Defect Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ctyp-257.patch    

 Description   

Problem

An empty intersection (I) is currently simplified to (U), but it
should be the same as Any.

Solution

Modify the intersection constructors to return Any on empty intersections.

Pull request: 45
Patch: ctyp-257.patch
Commit: 565ff8
Release: 0.3.9






[CTYP-255] Unparse should be flexible to unknown implementations Created: 22/Jul/15  Updated: 23/Jul/15  Resolved: 23/Jul/15

Status: Resolved
Project: core.typed
Component/s: Core type system
Affects Version/s: None
Fix Version/s: 0.3.9, 0.3.x

Type: Task Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ctyp-255.patch    

 Description   

Problem

Unparsing a type, often during unit testing via prn, requires the
type system implementation to be specified. This is too restrictive.

Solution

The unknown implementation should verbosely print types, and ignore
the current namespace.

Notes

Implementation extracted from this branch.

Waiting on: CTYP-256
Pull request: 43
Patch: ctyp-255.patch
Commit: 48c225
Release: 0.3.9






[CTYP-258] Correctly simplify negative type propositions in constructor Created: 23/Jul/15  Updated: 23/Jul/15  Resolved: 23/Jul/15

Status: Resolved
Project: core.typed
Component/s: Core type system
Affects Version/s: None
Fix Version/s: 0.3.9, 0.3.x

Type: Defect Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ctyp-258.patch    

 Description   

Problem

The negative type proposition constructor incorrectly simplifies
(! Any ...) to tt instead of (! Nothing ..) to ff.

Solution

Implement and/or test these optimisations:

  • (is Any ..) = tt
  • (is Nothing ..) = ff
  • (! Any ..) = ff
  • (! Nothing ..) = ff

Pull request: 46
Patch: ctyp-258.patch
Commit: 00b8d5
Release: 0.3.9






[CTYP-266] Elide checking of ns macro output for performance Created: 02/Aug/15  Updated: 02/Aug/15  Resolved: 02/Aug/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.10

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Problem

Checking the output of the ns macro is very slow.

=> (dotimes [i 3]
     (binding [*ns* *ns*]
       (time (cf (ns foo)))))
"Elapsed time: 527.803116 msecs"
"Elapsed time: 415.179303 msecs"
"Elapsed time: 497.35092 msecs"
nil

tc-ignore'ing the body delivers significant performance enhancements.

;; after patch
=> (dotimes [i 3]
     (binding [*ns* *ns*]
       (time (cf (ns foo)))))
"Elapsed time: 75.241128 msecs"
"Elapsed time: 60.542611 msecs"
"Elapsed time: 57.938648 msecs"
nil

Solution

tc-ignore body of ns macro, with an explicit nil return.

Pull request: 57
Commits: 8ce019d






[CTYP-250] Resolve Java interoperability based on static type information Created: 21/Jul/15  Updated: 02/Aug/15  Resolved: 02/Aug/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.10, 0.3.x

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Problem

Static type information can inform the Clojure compiler of non-reflective
Java interop. With the typed REPL, we now have a means to communicate this
information.

Approach

tools.analyzer.jvm returns :host-interop nodes for unresolved interop.
We first generate type hints based on the static types of the target/argument/
expected type, then passed the type-hinted AST back into the analyzer.

If this doesn't resolve the interop, we throw a type error a usual. If it does,
we type check as usual.

Pull request:

Commit: db3a3






[CTYP-264] deftype should rewrite method bodies Created: 01/Aug/15  Updated: 02/Aug/15  Resolved: 02/Aug/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.10

Type: Defect Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Commits:






[CTYP-265] Anonymous functions should rewrite body Created: 01/Aug/15  Updated: 02/Aug/15  Resolved: 02/Aug/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.10

Type: Defect Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Commits:






[CTYP-239] Search for .cljc files when checking a namespace Created: 25/Jun/15  Updated: 19/Oct/15  Resolved: 19/Oct/15

Status: Resolved
Project: core.typed
Component/s: Core type system
Affects Version/s: None
Fix Version/s: 0.3.12, 0.3.x

Type: Enhancement Priority: Minor
Reporter: Alejandro Assignee: Alejandro
Resolution: Completed Votes: 0
Labels: readerconditionals

Attachments: Text File 0001-Add-basic-unit-tests-for-CTYP-239.patch     Text File 0001-CTYP-239-Search-for-.cljc-files-when-checking-a-name.patch    
Patch: Code
Waiting On: Ambrose Bonnaire-Sergeant

 Description   

Currently core.typed assumes that Clojure files end with a .clj extension and ClojureScript files with .cljs. However, due to the introduction of reader conditionals to the language the .cljc extension is now valid for both Clojure and ClojureScript. core.typed should look for .cljc files in addition to .clj and .cljs.

The problem originates in the clojure.core.typed.coerce-utils namespace's ns->file function, since it hardcodes the .clj and .cljs extensions for finding Clojure and ClojureScript namespaces. When using this function from clojure.core.typed.analyze-clj namespace's ast-for-ns function it throws an exception.

Pull request: 58

Commits: 8dd3099 81aa140

Version: 0.3.12



 Comments   
Comment by Alejandro [ 25/Jun/15 9:38 AM ]

Since the current version of tools.analyzer.jvm that core.typed depends on doesn't support .cljc files the patch can't be applied yet.

Comment by Ambrose Bonnaire-Sergeant [ 19/Jul/15 11:16 AM ]

The latest tools.analyzer.jvm is inlined at clojure.core.typed.deps.clojure.tools.analyzer.jvm (see project.clj for the version).

Can this now move forward?

Comment by Brendan Tobolaski [ 31/Aug/15 1:47 PM ]

I see that there is a pull request for this on GitHub but it doesn't appear to have been merged onto master yet. Is this waiting on anything in particular?

Comment by Ambrose Bonnaire-Sergeant [ 31/Aug/15 2:18 PM ]

I'd merge if there was a test.

Comment by Piotr Jarzemski [ 24/Sep/15 2:18 PM ]

I created a basic set of unit tests for this issue (https://github.com/typedclojure/core.typed/pull/63). If that's not enough or if they aren't matching your requirements, please let me know.





[CTYP-281] Separate `load` monkey-patch and typed REPL Created: 24/Oct/15  Updated: 24/Oct/15  Resolved: 24/Oct/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.14

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Currently the nREPL middleware for the typed REPL is the only way to enable `load` monkeypatching.

These two features should be separated, since `load` monkeypatching works much more reliably in practice than the typed REPL.



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 24/Oct/15 9:09 PM ]

Commit: https://github.com/clojure/core.typed/commit/5366f19e91fd033a0d8218081a78629f22d7bd27





[CTYP-246] Gradually typed namespaces should import untyped vars with a contract Created: 19/Jul/15  Updated: 26/Oct/15  Resolved: 26/Oct/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.14, 0.3.x

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Problem

Gradual typing demands untyped code be protected by contracts. In core.typed,
occurrences of untyped vars in gradually typed code should be changed to add contracts.

For example, importing an untyped number from an untyped namespace should assert we
actually have a number at each dereference of the var.

(ns utyped)
(def n 42)
(ns gtyped
  {:core.typed true}
  (:require [clojure.core.typed :as t])
            [utyped :as utyped]))

(t/ann ^:rt-check utyped/n t/Int)

(inc utyped/n)
;;=> (inc (cast-untyped-var utyped/n))

The question is how to implement cast-untyped-var.

Solution

The first step is to decide on an appropriate way to communicate the
type for untyped vars. We already have :no-check vars for global
annotations, so it seems natural add a :rt-check annotations for
untyped vars whose type we want to enforce at runtime.

The problem of generating specific contracts for specific namespaces
like Typed Racket's require/typed we leave unsolved for now.

Pull request: 71
Commit: f75f8d2
Release: 0.3.13






[CTYP-286] Convert inlined dependencies back to regular jars Created: 02/Nov/15  Updated: 05/Nov/15  Resolved: 04/Nov/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.15

Type: Task Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Now core.async has a compatible tools.analyzer version, we should stop inlining dependencies.

PR: 76

Commit: afed234






[CTYP-287] Add contract system and `cast` expression Created: 02/Nov/15  Updated: 08/Nov/15  Resolved: 08/Nov/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.16

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Add a contract system a la racket/contract.

WIP PR: 74
Commit: 7250d32d






[CTYP-288] Type checker should understand clojure.core.typed/cast Created: 08/Nov/15  Updated: 11/Nov/15  Resolved: 11/Nov/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.18

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

`cast` now works well at runtime, however it's not plugged into the type checker to communicate the type that's being cast.

Pull request: 78
Commits: Type checker understands cast Use `cast` for contract generation






[CTYP-295] Update ns wrapper macro with Clojure 1.8 changes Created: 15/Nov/15  Updated: 15/Nov/15  Resolved: 15/Nov/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.19

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

https://github.com/clojure/clojure/commit/7f79ac9ee85fe305e4d9cbb76badf3a8bad24ea0

PR: 80
Commit: 7d64ff






[CTYP-299] Add per-namespace flag to check annotations at runtime Created: 18/Nov/15  Updated: 18/Nov/15  Resolved: 18/Nov/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.19

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Problem

Sometimes (often) static type checking is just too much work to get started with on a new namespace. Contracts, on the other hand, are an easy buy-in: a single contract check can live in complete isolation.

It would be nice to support two situations:

1. Say, we are starting to port a completely untyped namespace to typed. It would take a long time for core.typed to give us any sort of guarantee about our code. Instead, we write static type annotations that get converted into contracts, then gradually get to the point where enough annotations are present to switch to typed mode.

2. Conversely, say we are rapidly developing some typed code, and keeping the file well-typed every iteration is difficult or impossible. Now, we ask core.typed to enforce annotations at runtime instead of completely disabling the static type checker. This way, we have some notion that it will be straightforward to recover well-typedness when the iterations have slowed down, since the contracts keep things in check.

Solution

There are several approaches to generating contracts that are possible.

This is the implemented solution.

Each form is 'collect'ed like usual for type annotations, so annotations are stored as usual.

Then we recur down the AST and look for two things:

1. :def Nodes - here, if there is a corresponding annotation of type t and the :def is not a ^:no-check, we convert the def (def name init) to (def name (cast t init)).
2. ann-form nodes - we perform a similar transformation from (ann-form e t) to (ann-form (cast e t) t).

All static type checking is removed, including any tracking of local variable types.

Some remaining questions:

  • it would be nice to fail silently (or some non-error behaviour, eg. custom or best effort cast) if a contract cannot be generated based on the static type being too complicated.
  • what kind of function contract do we want to generate? One that checks recursive calls?

eg. Do we transform fact to fact2 or fact3? define/contract in racket does the latter, while racket/contract does the former.

(ann fact [Int -> Int])
(defn fact [n]
  (if (zero? n) 1 (* n (fact n))))

;; this checks fact2's input at each recursive call.
;; The implementation of fact2 must be internally consistent
;; with the interface it advertises, [Int -> Int].
;; Also expensive.
(def fact2 
  (cast [Int -> Int]
    (fn [n]
      (if (zero? n) 1 (* n (fact2 n))))))

;; Less expensive, only one check per call, recursive calls don't
;; need to be [Int -> Int].
;; Difference: fact3 is now a local variable rather than a var dereference,
;; if the semantics of fact3 rely on fact3 being a var, this seems bad.
(defn fact3 [n]
  (letfn [(fact3 [n]
            (if (zero? n) 1 (* n (fact3 n))))]
    (cast [Int -> Int] (fact3 n))))

Pull request: 84
Commit: 868a4ff






[CTYP-300] Support HMap contract generation Created: 19/Nov/15  Updated: 19/Nov/15  Resolved: 19/Nov/15

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.20

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Implement contract generation for HMap's.

eg.

(cast '{:a 1} {:a 1})
;=> {:a 1}

((:a (cast '{:a [Int -> Int]} {:a str}))
 1)
; Error + blame

Pull request: 85
Commit: a34bcd12






[CTYP-304] Upgrade to Clojure 1.8.0 Created: 27/Jan/16  Updated: 27/Jan/16  Resolved: 27/Jan/16

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.20

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Pull request: 90
Commit: 7330f67
Release: 0.3.20






[CTYP-283] Directly-linking in Clojure 1.8.0 interferes with load monkey-patching Created: 27/Oct/15  Updated: 27/Jan/16  Resolved: 27/Jan/16

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.15, 0.3.20

Type: Defect Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Clojure 1.8.0's jar contains clojure.core with directly linked vars.

This means our trick of monkey-patching `load` no longer works.

Instead, we must also monkey-patch `require` and `use`, and completely
copy their implementations.

20 November 2015 reopen

clojure.core/compile similarly uses `load`. It's safe to insert core.typed into this pipeline because we pass the results of type checking to Compiler.java anyway, so the results of type checking can be AOT compiled.

End reopen

Future Revert (Completed, see 27th January changes)

Ideally CLJ-1845 fixes the original problem, but it is not clear if it actually does.

user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched") (apply f args))))
#object[user$eval1241$fn__1242$fn__1243 0x1c857e6 "user$eval1241$fn__1242$fn__1243@1c857e6"]
user=> (load)
"patched"
nil
user=> (require 'clojure.core :reload)
nil
user=> (require 'clojure.tools.analyzer :reload)
nil
user=> (require 'clojure.tools.analyzer :reload-all)
nil

This should print "patched" after every `require`.

Pull request: 72
Commit: fe7ae4a
Release: 0.3.15

20 November reopen

Pull request: 87
Commit: 9cd4f720
Release: 0.3.20

End 20 November reopen

27 Jan 2015 Revert

Now Clojure 1.8.0 is released and there are no direct-linking issues, we can revert both patches.

Pull request: 91
Commits: 6b92bb 9eb6c9
Release: 0.3.20

End 27 Jan 2015 Revert



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 19/Nov/15 10:21 PM ]

No longer needed in 1.8.0-RC1, `load` is declared dynamic.

Comment by Ambrose Bonnaire-Sergeant [ 20/Nov/15 9:02 AM ]

`clojure.core/compile` also uses `load`, so that must also be monkey-patched.

Comment by Ambrose Bonnaire-Sergeant [ 27/Jan/16 2:51 PM ]

Reopening as Clojure 1.8.0 fixes the direct-linking issue.





[CTYP-285] Cljc reader conditionals in ns form cause core.typed to skip checking namespace Created: 02/Nov/15  Updated: 29/Jan/16  Resolved: 29/Jan/16

Status: Resolved
Project: core.typed
Component/s: Core type system
Affects Version/s: 0.3.14
Fix Version/s: 0.3.20

Type: Defect Priority: Minor
Reporter: Kaylen Wheeler Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Problem

(See the following code repository for a working example: https://github.com/frenchy64/typed-cljc-bug)

When cljc reader conditionals (#? and #?@) are used in the ns form of a cljc file, check-ns returns :ok, but does not actually check the namespace.

The following error message is displayed, complaining of a lacking NS form:

; => (t/check-ns)
;Initializing core.typed ...
;Building core.typed base environments ...
;Finished building base environments
;"Elapsed time: 6214.616942 msecs"
;core.typed initialized.
;Start collecting cljc-fail.core
;WARNING: File for cljc-fail.core not found on classpath: cljc_fail/core.cljc
;Finished collecting cljc-fail.core
;Collected 1 namespaces in 114.423761 msecs
;WARNING: File for cljc-fail.core not found on classpath: cljc_fail/core.cljc
;WARNING: File for cljc-fail.core not found on classpath: cljc_fail/core.cljc
;Not checking cljc-fail.core (ns form missing)
;Checked 1 namespaces  in 120.673717 msecs
; :ok

Solution

Bump tools.namespace to 0.2.11.

Pull request: 93
Commit: 9beca4b8
Version: 0.3.20



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 02/Nov/15 3:56 PM ]

Fix is to update tools.namespace https://github.com/clojure/tools.namespace/blob/master/CHANGES.md#version-0211-on-19-jun-2015





[CTYP-307] Override `eval` to type check code in typed namespaces Created: 31/Jan/16  Updated: 31/Jan/16  Resolved: 31/Jan/16

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.21

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Problem

Monkey-patching a typed load isn't enough for real usage. By monkey-patching a typed eval, we can type check REPL interactions without the need for a separate REPL.

Solution

Add new clojure.core.typed/install var that monkey-patches both load and eval.

The typed eval looks at the current :lang metadata, instead of touching the file system with tools.namespace.

New (Leiningen) bootstrap code:

:injections [(require 'clojure.core.typed)
             (clojure.core.typed/install)]

Pull request: 96
Commit: 0e71ef8
Version: 0.3.21






[CTYP-18] Implement equality filters Created: 10/Mar/13  Updated: 31/Jan/16  Resolved: 31/Jan/16

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Declined Votes: 0
Labels: None


 Description   

Equality filters show that two local bindings are essentially equivalent (eg. aliased). This is useful where macros alias user-known locals with gensyms, like in :as map destructuring.






[CTYP-280] Breaks (my) repl Created: 28/Sep/15  Updated: 31/Jan/16  Resolved: 31/Jan/16

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Nick DeCoursin Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None
Environment:

Clojure 1.7.0
org.clojure/core.typed "0.3.11"
cider/cider-nrepl "0.10.0-SNAPSHOT"



 Description   

My repl was working fine until I added this:

:repl-options {:nrepl-middleware
                       [clojure.core.typed.repl/wrap-clj-repl]}

Now, my error is this:

REPL-y 0.3.7, nREPL 0.2.10
Clojure 1.7.0
OpenJDK 64-Bit Server VM 1.7.0_79-b14
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
    Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user=> (ns ^:core.typed my-ns)
Initializing core.typed ...
Building core.typed base environments ...
Finished building base environments
"Elapsed time: 1033.36803 msecs"
core.typed initialized.
ERROR: Unhandled REPL handler exception processing message {:code (ns ^:core.typed my-ns), :id 6cf350c4-d0af-4605-9c74-2a34060d530d, :op eval, :session 2f60f7e2-3ed5-48f5-bea3-4d4b4811cc4c}
java.lang.NoClassDefFoundError: clojure/tools/nrepl/transport/Transport
    at clojure.core.typed.repl$handle_eval.invoke(repl.clj:89)
    at clojure.core.typed.repl$wrap_clj_repl$fn__27725.invoke(repl.clj:192)
    at clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__414.invoke(middleware.clj:22)
    at cider.nrepl.middleware.test$wrap_test$fn__8120.invoke(test.clj:201)
    at clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__414.invoke(middleware.clj:22)
    at clojure.tools.nrepl.middleware.session$session$fn__729.invoke(session.clj:192)
    at clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__414.invoke(middleware.clj:22)
    at cider.nrepl.middleware.classpath$wrap_classpath$fn__2688.invoke(classpath.clj:24)
    at clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__414.invoke(middleware.clj:22)
    at cider.nrepl.middleware.debug$wrap_debug$fn__4389.invoke(debug.clj:328)
    at clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__414.invoke(middleware.clj:22)
    at clojure.tools.nrepl.server$handle_STAR_.invoke(server.clj:19)
    at clojure.tools.nrepl.server$handle$fn__798.invoke(server.clj:28)
    at clojure.core$binding_conveyor_fn$fn__4444.invoke(core.clj:1916)
    at clojure.lang.AFn.call(AFn.java:18)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: clojure.tools.nrepl.transport.Transport
    at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    ... 19 more

Here's my profiles.clj:

{:user {:plugins [[lein-exec "0.3.5"]
                  [lein-pprint "1.1.1"] ;; lein pprint ;; print project map
                  [lein-ancient "0.6.7"] ;; lein ancient ; Checks for outdated plugins
                  [lein-kibit "0.1.2"] ;; suggests code to be rewritten to be more idiomatic
                  [org.clojure/tools.namespace "0.2.11"] ;;detects changes to source files and reloads the changed files and their dependents in the correct order
                  [cider/cider-nrepl "0.10.0-SNAPSHOT"]]
        :dependencies [[com.cemerick/pomegranate "0.3.0"]]}
 :repl {:plugins []
        :dependencies [[org.clojure/math.numeric-tower "0.0.4"]]}
 :dev  {:plugins []
        :dependencies [[org.clojure/core.typed "0.3.11"]]
        :repl-options {:nrepl-middleware
                       [clojure.core.typed.repl/wrap-clj-repl]}}}

Thanks!



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 30/Sep/15 8:27 AM ]

I can reproduce in my own environment. I have no idea what is happening.

Comment by Ambrose Bonnaire-Sergeant [ 31/Jan/16 7:10 PM ]

Prefer the typed REPL over this https://github.com/clojure/core.typed#getting-started





[CTYP-308] Enable sanity-checking compilation of core.typed-rt project Created: 31/Jan/16  Updated: 31/Jan/16  Resolved: 31/Jan/16

Status: Resolved
Project: core.typed
Component/s: None
Affects Version/s: None
Fix Version/s: 0.3.23

Type: Task Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Problem

The core.typed-rt project (under module-rt/pom.xml) does not compile its sources.

Solution

Enable compilation, but omit the resulting files from the final jar.

Pull request: 97
Commit: d4c0206
Version: 0.3.23






[CTYP-248] Move lexical environment to an easily accessible location Created: 20/Jul/15  Updated: 20/Jul/15  Resolved: 20/Jul/15

Status: Resolved
Project: core.typed
Component/s: Core type system
Affects Version/s: None
Fix Version/s: 0.3.8, 0.3.x

Type: Task Priority: Trivial
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: refinement-types

Attachments: Text File move-lex-env.patch    

 Description   

Problem

To start work on refinement types, we probably want the lexical environment to be easily accessible, especially from type-rep.

Approach

Add a new dynamic variable in util-vars and change existing dereferences of *lexical-env* to a function somewhere.

Code review: CTYP-248
Patch: move-lex-env.patch
Commit: CTYP-248
To appear: 0.3.8






[CTYP-113] Better documentation for override-method Created: 04/Mar/14  Updated: 21/Jul/15  Resolved: 21/Jul/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.8, 0.3.x

Type: Enhancement Priority: Trivial
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 2
Labels: documentation

Attachments: Text File 0001-Update-override-method-documentation.patch    

 Description   

I've recently had to use override-method and could not find any usage examples anywhere. The doc string wasn't much help either, but I finally figured out how to use it. I've added my notes to override-method's doc string (see attached patch) in the hope that they are useful.

Patch: 0001-Update-override-method-documentation.patch
Pull request: 31
Commit: f1ed66c
Release: 0.3.8



 Comments   
Comment by Tobias Kortkamp [ 15/Aug/14 1:32 PM ]

I've recently had to use override-method and could not find any usage examples anywhere. The doc string wasn't much help either, but I finally figured out how to use it. I've added my notes to override-method's doc string (see attached patch) in the hope that they are useful.





[CTYP-251] Remove dead code clojure.core.typed.check.fn-method Created: 22/Jul/15  Updated: 22/Jul/15  Resolved: 22/Jul/15

Status: Resolved
Project: core.typed
Component/s: Core type system
Affects Version/s: None
Fix Version/s: 0.3.9, 0.3.x

Type: Task Priority: Trivial
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ctyp-251.patch    

 Description   

clojure.core.typed.check.fn-method is dead code, it should be removed.

Pull request: 38
Patch: ctyp-251.patch
Commit: 7ff05e
Release: 0.3.9






[CTYP-253] Remove static/instance flag in check-method Created: 22/Jul/15  Updated: 22/Jul/15  Resolved: 22/Jul/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.9, 0.3.x

Type: Task Priority: Trivial
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ctyp-253.patch    

 Description   

Problem

The function clojure.core.typed.check.method/check-function takes an extra
argument that can be easily inferred from other arguments.

Solution

Delete the inst? flag and decide whether we have a static/instance method based
on the expression argument.

Pull request: 40
Patch: ctyp-253.patch
Commit: 9a217f
Release: 0.3.9






[CTYP-252] Suppress tools.analyzer's warn-on-reflection Created: 22/Jul/15  Updated: 22/Jul/15  Resolved: 22/Jul/15

Status: Resolved
Project: core.typed
Component/s: Clojure Checker
Affects Version/s: None
Fix Version/s: 0.3.9, 0.3.x

Type: Task Priority: Trivial
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ctyp-252.patch    

 Description   

Problem

We use tools.analyzer to analyze code before we emit and send to the standard
Clojure compiler for evaluation. We are planning to rewrite reflective calls,
so we don't want a warning if the initial analysis is reflective, but the final
evaluation is non-reflective.

Solution

Remove the warn-on-reflection pass from tools.analyzer.

Pull request: 39
Patch: ctyp-252.patch
Commit: 7cbc7d
Release: 0.3.9






[CTYP-254] Add flag to enable AST rewriting Created: 22/Jul/15  Updated: 22/Jul/15  Resolved: 22/Jul/15

Status: Resolved
Project: core.typed
Component/s: Core type system
Affects Version/s: None
Fix Version/s: 0.3.9, 0.3.x

Type: Task Priority: Trivial
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ctyp-254.patch    

 Description   

Problem

Since we have both an offline (check-ns) way to type check, and online
(typed REPL), it only makes sense to rewrite the AST in certain cases.

Solution

Add a dynamic variable *can-rewrite* which is true when AST rewriting
makes sense.

Pull request: 41
Patch: ctyp-254.patch
Commit: 9e7b73
Release: 0.3.9






[CTYP-256] Add :unknown implementation to impl-case Created: 22/Jul/15  Updated: 23/Jul/15  Resolved: 23/Jul/15

Status: Resolved
Project: core.typed
Component/s: Core type system
Affects Version/s: None
Fix Version/s: 0.3.9, 0.3.x

Type: Task Priority: Trivial
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ctyp-256.patch    

 Description   

Problem

Sometimes we want a default case when no implementation is specified in
impl-case. Since it throws an exception when falling through, we need
an explicit :unknown implementation.

Solution

Add :unknown implementation by default.

Pull request: 44
Patch: ctyp-256.patch
Commit: 856abf
Release: 0.3.9






Generated at Wed Jul 27 14:13:47 CDT 2016 using JIRA 4.4#649-r158309.