<< Back to previous view

[CLJS-2048] Internal compiler error when depending on Slate via npm-deps Created: 23/May/17  Updated: 23/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Dieter Komendera Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ClojureScript 1.9.542


Attachments: Zip Archive cljsslate.zip    

 Description   

Compiling a project which depends on slate via :npm-deps fails with an internal compiler error.

To reproduce:
1) download the attached sample project
2) put a cljs.jar into the sample project, (i.e via curl -L https://github.com/clojure/clojurescript/releases/download/r1.9.542/cljs.jar -o cljs.jar)
3) build the project with java -cp cljs.jar:src clojure.main build.clj

The build call looks like this:

(cljs/build
"src"
{:main 'cljsslate.main
:output-to "out/main.js"
:verbose true
:optimizations :none
:pretty-print true
:npm-deps {:react "15.5.4"
:react-dom "15.5.4"
:slate "0.20.1"}})

Produces the following error:
-----------
Exception in thread "main" java.lang.RuntimeException: INTERNAL COMPILER ERROR.
Please report this problem.

null
Node(NAME decodeHTMLStrict): /Users/kommen/work/cljs-issues/cljsslate/node_modules/entities/lib/decode.js:7:4
decodeHTMLStrict = getStrictDecoder(entityMap);
Parent(VAR): /Users/kommen/work/cljs-issues/cljsslate/node_modules/entities/lib/decode.js:6:0
var decodeXMLStrict = getStrictDecoder(xmlMap),
, compiling/Users/kommen/work/cljs-issues/cljsslate/build.clj:3:1)
at clojure.lang.Compiler.load(Compiler.java:7391)
at clojure.lang.Compiler.loadFile(Compiler.java:7317)
at clojure.main$load_script.invokeStatic(main.clj:275)
at clojure.main$script_opt.invokeStatic(main.clj:335)
at clojure.main$script_opt.invoke(main.clj:330)
at clojure.main$main.invokeStatic(main.clj:421)
at clojure.main$main.doInvoke(main.clj:384)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.lang.Var.invoke(Var.java:379)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: INTERNAL COMPILER ERROR.
Please report this problem.

null
Node(NAME decodeHTMLStrict): /Users/kommen/work/cljs-issues/cljsslate/node_modules/entities/lib/decode.js:7:4
decodeHTMLStrict = getStrictDecoder(entityMap);
Parent(VAR): /Users/kommen/work/cljs-issues/cljsslate/node_modules/entities/lib/decode.js:6:0
var decodeXMLStrict = getStrictDecoder(xmlMap),

at com.google.javascript.rhino.Node.replaceWith(Node.java:868)
at com.google.javascript.jscomp.ProcessCommonJSModules$RewriteModule.updateNameReference(ProcessCommonJSModules.java:1060)
at com.google.javascript.jscomp.ProcessCommonJSModules$RewriteModule.maybeUpdateName(ProcessCommonJSModules.java:939)
at com.google.javascript.jscomp.ProcessCommonJSModules$RewriteModule.visit(ProcessCommonJSModules.java:701)
at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:662)
at com.google.javascript.jscomp.NodeTraversal.traverseChildren(NodeTraversal.java:734)
at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:658)
at com.google.javascript.jscomp.NodeTraversal.traverseChildren(NodeTraversal.java:734)
at com.google.javascript.jscomp.NodeTraversal.handleScript(NodeTraversal.java:611)
at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:637)
at com.google.javascript.jscomp.NodeTraversal.traverse(NodeTraversal.java:316)
at com.google.javascript.jscomp.NodeTraversal.traverseEs6(NodeTraversal.java:574)
at com.google.javascript.jscomp.ProcessCommonJSModules.process(ProcessCommonJSModules.java:127)
at com.google.javascript.jscomp.Compiler.processAMDAndCommonJSModules(Compiler.java:1943)
at com.google.javascript.jscomp.Compiler.parseInputs(Compiler.java:1634)
at com.google.javascript.jscomp.Compiler.parse(Compiler.java:866)
at cljs.closure$fn__4732.invokeStatic(closure.clj:1601)
at cljs.closure$fn__4732.invoke(closure.clj:1593)
at clojure.lang.MultiFn.invoke(MultiFn.java:238)
at cljs.closure$process_js_modules$fn__4995.invoke(closure.clj:2156)
at clojure.core$map$fn__4785.invoke(core.clj:2646)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:521)
at clojure.core$seq__4357.invokeStatic(core.clj:137)
at clojure.core$apply.invokeStatic(core.clj:641)
at clojure.core$mapcat.invokeStatic(core.clj:2674)
at cljs.closure$process_js_modules.invokeStatic(closure.clj:2138)
at cljs.closure$build.invokeStatic(closure.clj:2228)
at cljs.build.api$build.invokeStatic(api.clj:201)
at cljs.build.api$build.invoke(api.clj:189)
at cljs.build.api$build.invokeStatic(api.clj:192)
at cljs.build.api$build.invoke(api.clj:189)
at user$eval24.invokeStatic(build.clj:6)
at user$eval24.invoke(build.clj:6)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.load(Compiler.java:7379)
... 11 more
Caused by: java.lang.NullPointerException
... 48 more
-----------






[CLJS-2047] Bump tools.reader to 1.0.0-beta4 Created: 23/May/17  Updated: 23/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

[org.clojure/tools.reader "1.0.0-beta4"] is used by core.async and conflicts with CLJS.






[CLJS-2046] Optimize expression in call position Created: 20/May/17  Updated: 20/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: A. R Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Just what CLJS-855 did for arguments, should be done for a function expression.

Examples:

(@a :b)
((:x m) :b)

Currently, even with static-fns these both emit (inefficient) .call code. The expression should be put into a let binding and then the compiler can emit efficient code that checks for the IFn protocol.

Also needed for CLJS-2041 .






[CLJS-2045] sort-by: Avoid re-creating comparator Created: 20/May/17  Updated: 20/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: A. R Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The fn->comparator call should be lifted:

(sort (fn [x y] ((fn->comparator comp) (keyfn x) (keyfn y))) coll)
(let [comparator (fn->comparator comp)]
  (sort (fn [x y] (comparator (keyfn x) (keyfn y))) coll))

Also, fn->comparator is again called on the function in sort, not sure how to avoid that unless we copy the sort code into sort-by.






[CLJS-2044] Optimize generated code for multi-arity+variadic defn Created: 20/May/17  Updated: 22/May/17  Resolved: 22/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Duplicate Votes: 1
Labels: None


 Description   

This code

(ns demo.ns)

(defn x
  ([a] a)
  ([a b] a)
  ([a b & more] a))

generates code like this

demo.ns.x = function demo$ns$x(var_args) {
  var args6685 = [];
  var len__4636__auto___6691 = arguments.length;
  var i__4637__auto___6692 = 0;
  while (true) {
    if (i__4637__auto___6692 < len__4636__auto___6691) {
      args6685.push(arguments[i__4637__auto___6692]);

      var G__6693 = i__4637__auto___6692 + 1;
      i__4637__auto___6692 = G__6693;
      continue;
    } else {
    }
    break;
  }

  var G__6690 = args6685.length;
  switch (G__6690) {
    case 1:
      return demo.ns.x.cljs$core$IFn$_invoke$arity$1(arguments[0]);

      break;
    case 2:
      return demo.ns.x.cljs$core$IFn$_invoke$arity$2(
        arguments[0],
        arguments[1]
      );

      break;
    default:
      var argseq__4655__auto__ = new cljs.core.IndexedSeq(
        args6685.slice(2),
        0,
        null
      );
      return demo.ns.x.cljs$core$IFn$_invoke$arity$variadic(
        arguments[0],
        arguments[1],
        argseq__4655__auto__
      );
  }
};

// rest of code omitted

The generated args6685 array is only used by the default case which then just .slice(2) it again. This should be able to just arguments.slice(2) and skip the temp array creation completely? CLJS code will use the demo.ns.x.cljs$core$IFn$_invoke$arity$* functions directly so it doesn't matter much but could be improved nonetheless.



 Comments   
Comment by A. R [ 20/May/17 3:41 AM ]

Note, arguments isn't a real array: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/arguments

It'd need a [].slice.call(arguments).

I'd say reuse cljs.core.aclone so VM's can optimize that function when it get's called a lot.

Also IndexedSeq provides us with an offset parameter, so we can use that.

default:
      return demo.ns.x.cljs$core$IFn$_invoke$arity$variadic(
        arguments[0],
        arguments[1],
        new cljs.core.IndexedSeq(cljs.core.aclone(arguments), 2, null))
      );

EDIT: Ignore me, passing arguments is bad: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#32-leaking-arguments

CLJS is already ahead

Comment by Thomas Heller [ 20/May/17 8:04 AM ]

I knew the V8 doesn't optimize arguments but I think moving the array creation into the {default should still be better? The fixed arity calls don't use the array so it shouldn't be allocated for these cases.

Should probably benchmark this to see if there is any possible gain to be had. Just noticed this while looking through some generated code and my instinct said that we can probably optimize this. My instinct is often wrong though.

Comment by A. R [ 20/May/17 10:17 AM ]

I agree. We should probably copy the compiler (see cljs.compiler/emit-arguments-to-array) and add a start-slice parameter to copy-arguments. Also moving the let into the default case generates "good" code, ie. does NOT generate an IIFE expression:

(let [~args-sym (array)]
  (copy-arguments ~args-sym ~maxfa)
  (let [argseq# (new ^::ana/no-resolve cljs.core/IndexedSeq
                     ~args-sym 0 nil)]
    (. ~rname
       (~'cljs$core$IFn$_invoke$arity$variadic
         ~@(dest-args maxfa)
         argseq#))))
Comment by Francis Avila [ 20/May/17 2:28 PM ]

Relevant: CLJS-1641, CLJS-1678

Comment by Thomas Heller [ 22/May/17 5:36 AM ]

Oops, duplicate: https://dev.clojure.org/jira/browse/CLJS-1641





[CLJS-2043] Remove checks made redundant by CLJS-2040 Created: 20/May/17  Updated: 20/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Thomas Heller Assignee: Thomas Heller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

CLJS-2040 added a check to see if we have analyzer metadata for a given ns. The old checks are still in there but would also be covered by the new check. We should probably remove them.

https://github.com/clojure/clojurescript/commit/77e01a01af9f45c76cfa34aa67bfae154b075544#diff-55b85385d2d0bfb6dc20d59ed982d5c8R953






[CLJS-2042] Variadic invoke calls array_seq inefficiently Created: 18/May/17  Updated: 20/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: A. R Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-2042.patch    

 Description   

The compiler emits an inefficient call:

variadic-invoke
       (let [mfa (:max-fixed-arity variadic-invoke)]
        (emits f "(" (comma-sep (take mfa args))
               (when-not (zero? mfa) ",")
               "cljs.core.array_seq([" (comma-sep (drop mfa args)) "], 0))"))

Since array_seq is itself variadic this can be optimized. Should probably be:

cljs.core.prim_seq.cljs$core$IFn$_invoke$arity$2$(...,0)

Or even a {{new IndexedSeq([...],0,nil)}}?



 Comments   
Comment by David Nolen [ 19/May/17 3:21 PM ]

Ok.





[CLJS-2041] Compiler flag to drop Function.prototype.call invokes Created: 18/May/17  Updated: 20/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: Next

Type: Enhancement Priority: Minor
Reporter: A. R Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-2041.patch    

 Description   

Background

If the compiler doesn't know the arity of the function and :static-fns is true, it'll emit code to check if this arity exists or otherwise use .call(null, a0)
Example:

(fn [x] (x 1))
function(x){
x.$cljs$core$IFn$_invoke$arity$1$ ? x.$cljs$core$IFn$_invoke$arity$1$(1) : x.call(null, 1)

Furthermore, any data structures/types that implement IFn will attach .call and .apply to the type's prototype. This (often multi arity) function then calls the appropriate protocol functions depending on the argument.

Problems

The .call is slightly slower.
If the function only has one arity, it'll get called with the .call instead of a faster x(1).

Possible improvement

Since, with :static-fns the compiler checks if the protocol exists on the function/object the .call is never used unless it's a function (NOT a data structure) with exactly one arity.

We can also avoid emitting the attaching of the .call and .apply to any data structures since they'll never be used. (Again, with :static-fns)

Problems & Evaluation

On my local 18k LOC project, I only ran into one problem in a single line of datascript that used:

((.-rschema db) prop)

This generated (even with :static-fns set) db.rschema.call(null,prop) which failed since I removed the .call from the prototype of the PersistentHashMap (the rschema).

Fix was easy:

(let [rschema (.-rschema db)]
  (rschema property))

Which then resulted that the code checked for the protocol at the call site.

Implementation

Q1: Should :static-fns:

  1. No emission of .call and .apply on any IFn protocol implementation? (See add-ifn-methods in core.cljc.
  2. Emission of x.$cljs$core$IFn$_invoke$arity$1$ ? x.$cljs$core$IFn$_invoke$arity$1$(1) : x(1)

Or another compiler option so users can try it out?

Q2: Should

((.-rschema db) prop)

result in checking for IFn protocol?



 Comments   
Comment by A. R [ 18/May/17 2:45 PM ]

That patch is bad. binding doesn't work consecutively.

Comment by Thomas Heller [ 18/May/17 4:47 PM ]

Can you provide a full example?

(fn [x] (x 1))

What is x?

Comment by A. R [ 19/May/17 1:13 AM ]

x can be a few things:

  1. Datatype implementing IFn
  2. A JS function
  3. A CLJS function with exactly 1 arity
  4. A CLJS function with multiple arity
  5. A CLJS function with variadic arity

The call sites emits code that check if the arity exists. So (1) & (4) will never be called through the dispatcher. (2) & (3) will be fine being called normally by f. The only problem is (5) which is very rare.

(defn foo [x] (x 1 2 3 4 5))
(foo =)

Will require the dispatcher generated & working. In my code I never used that pattern so I could even remove all dispatcher functions and everything still worked. Note: The patch doesn't remove the dispatchers, this will still work with the patch. But a more aggressive patch could remove them and throw and error about "ineffcient" invokes. (That's actually how I found CLJS-2042)
(Workaround would be to use apply above).

But to answer your question:

(defn run!
  [proc coll]
  (reduce (fn [_ x] (proc x)) nil coll)
  nil)

Always calls proc with .call if a one arity function is passed (without the patch).

Comment by David Nolen [ 19/May/17 8:50 AM ]

A.R. 5) is probably a deal-breaker. We should avoid statements like "rare" in assessments when we can't possibly know what people are doing in the wild with a 5 year old OSS project.

Comment by David Nolen [ 19/May/17 9:12 AM ]

After brief discussion I agree that after `IFn` was properly implemented `.call` becomes vestigial in theory. However downstream libraries may depend on this detail so a flag is desirable for now.

Patch review. Please keep patches more tightly focused. Remove dropping the generated `.call` code code for now. Let's call the flag *fn-invoke-call*. One of your code gen blocks looks inverted to me with respect to the flag. Please fix these issues and I will re-review.





[CLJS-2040] Fix assumption that all closure-compliant JS is goog.* Created: 17/May/17  Updated: 19/May/17  Resolved: 19/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File direct-js-invokes.patch    
Patch: Code and Test

 Description   

The CLJS compiler assumes that all Closure compatible JS will be in the `goog.*` namespace.

This assumption is bad and produces non-optimal code if there is any other Closure JS files in a build.

(ns foo.main
  (:require [dummy.foo :as x]
            [goog.string :as gstr]))

;; good
(gstr/urlEncode "foo")

;; bad
(x/demo 1 2)

With dummy.foo being the Closure JS file will produce:

// Compiled by ClojureScript 1.9.521 {:static-fns true}
goog.provide('foo.main');
goog.require('cljs.core');
goog.require('dummy.foo');
goog.require('goog.string');
goog.string.urlEncode("foo");
(dummy.foo.demo.cljs$core$IFn$_invoke$arity$2 ? dummy.foo.demo.cljs$core$IFn$_invoke$arity$2((1),(2)) : dummy.foo.demo.call(null,(1),(2)));

//# sourceMappingURL=main.js.map

The gstr/urlEncode uses the good form but the x/demo invoke uses the CLJS style invoke and will always end up in .call.

The code still works but should be optimized.

dummy.foo.demo((1),(2));

The added patch adds an additional check to see if we have analyzer data for a given invoke, if that is not the case it will treat it as a goog? call.



 Comments   
Comment by Thomas Heller [ 17/May/17 10:11 AM ]

I created a quick demo here:
https://github.com/thheller/cljs-issues/tree/master/CLJS-2040

With the bad invoke code here:
https://github.com/thheller/cljs-issues/blob/master/CLJS-2040/out/foo/main.js

Comment by David Nolen [ 19/May/17 3:20 PM ]

fixed https://github.com/clojure/clojurescript/commit/3501c40b32db49292e9c9550bc143d1b74a473d6





[CLJS-2039] Extraneous argument in ChunkBuffer Object.chunk declaration Created: 16/May/17  Updated: 19/May/17  Resolved: 19/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Mulvaney Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2039.patch    

 Description   

There is an extra unused argument at the end of the method declaration for ChunkBuffer Object.chunk



 Comments   
Comment by David Nolen [ 19/May/17 3:23 PM ]

fixed https://github.com/clojure/clojurescript/commit/c567440338925cb6885d04385c37f88b9611a35b





[CLJS-2038] self calls do not optimize - regression Created: 15/May/17  Updated: 18/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: None

Type: Defect Priority: Major
Reporter: A. R Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This is a regression of:

https://dev.clojure.org/jira/browse/CLJS-275



 Comments   
Comment by A. R [ 18/May/17 2:19 AM ]

This issue can be solve by changing the defn macro for the "simple" case and carrying the function name over to the function:

(core/list 'def (with-meta name m)
  (cons `fn (cons name fdecl)))

This isn't done in clojure because of: https://dev.clojure.org/jira/browse/CLJ-809

Though I don't think that's and issue in CLJS since we don't have real vars anyways and can't redefine {{def}}s.





[CLJS-2037] Throw if overwriting alias in current namespace Created: 14/May/17  Updated: 15/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: António Nuno Monteiro
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We should make this behavior the same as Clojure, where requiring a different namespace under and existent alias throws



 Comments   
Comment by David Nolen [ 15/May/17 7:59 AM ]

Go for it.





[CLJS-2036] Relative path exception thrown when :preloads requires a :foreign-lib Created: 13/May/17  Updated: 13/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Oliver George Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Windows 10
[org.clojure/clojurescript "1.9.542"]



 Description   

I see an error when using :preloads and :foreign-libs.

java.lang.IllegalArgumentException:
C:\Temp\canidep\src\uilib.js is not a relative path, compiling:(C:\Temp\canidep\scripts\build.clj:5:1)

Unable to find source-code formatter for language: project.clj. Available languages are: javascript, sql, xhtml, actionscript, none, html, xml, java
(defproject canidep "0.1.0-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.9.0-alpha16"]
                 [org.clojure/clojurescript "1.9.542"]]
  :jvm-opts ^:replace ["-Xmx1g" "-server"]
  :source-paths ["src" "target/classes"]
  :clean-targets ["out" "release"]
  :target-path "target")
Unable to find source-code formatter for language: scripts/build.clj. Available languages are: javascript, sql, xhtml, actionscript, none, html, xml, java
(require '[cljs.build.api :as b])
(b/build "src"
  {:main 'canidep.core
   :output-to "out/canidep.js"
   :output-dir "out"
   :verbose true
   :preloads '[canidep.preload]})
src/canidep/core.cljs
(ns canidep.core
  (:require [cljsjs.uilib]))

(println "Hello world!")
src/canidep/preload.cljs (works)
(ns canidep.preload)

(println "preload works without require")
src/canidep/preload.cljs (fails)
(ns canidep.preload
  (:require [cljsjs.uilib]))

(println "preload fails with require")
src/uilib.ext.js
// Nothing to see
src/uilib.js
// Nothing to see


 Comments   
Comment by Oliver George [ 13/May/17 11:49 PM ]

And the test deps file

src/deps.cljs
{:externs ["uilib.ext.js" ]
 :foreign-libs [{:file     "uilib.js"
                 :provides ["cljsjs.uilib"]}]}
Comment by Oliver George [ 13/May/17 11:53 PM ]

Unable to reproduce on OSX. Seems Windows specific.





[CLJS-2035] Self-host: Add map-entry-test to self-parity Created: 12/May/17  Updated: 15/May/17  Resolved: 15/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-2035.patch    
Patch: Code and Test

 Description   

Add the new tests added with CLJS-2013 to self-parity.test.



 Comments   
Comment by David Nolen [ 15/May/17 8:06 AM ]

fixed https://github.com/clojure/clojurescript/commit/5cc7865a1e2e9aecc24f975454721f621ba8ee60





[CLJS-2034] Sequence and Eduction produce infinite loop in transducer that appends to the reduction Created: 12/May/17  Updated: 12/May/17  Resolved: 12/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: transducers

Attachments: Text File CLJS-2034.patch    
Patch: Code and Test

 Description   

Example: a transducer that appends :foo to the result of the reduction:

(defn xf []
  (fn [rf]
    (fn
      ([] (rf))
      ([result] (rf result :foo))
      ([result input]
       (rf result input)))))

(sequence (xf) [1 2 3])

In Clojure, the above code yields

'(1 2 3 :foo)
. In ClojureScript, it results in an infinite loop. The same happens with `eduction`.
However,
(into [] (xf) [1 2 3])
doesn't produce an error.



 Comments   
Comment by António Nuno Monteiro [ 12/May/17 2:13 PM ]

I'm looking into fixing this one.

Comment by António Nuno Monteiro [ 12/May/17 3:46 PM ]

The implementation of transducers in ClojureScript tracked an old counterpart in
the Clojure codebase. This patch addresses the change introduced in the
following commit to Clojure, which replaced `LazyTransformer` with
`TransformerIterator`, effectively making the transducer behavior akin to the
one in Clojure.

https://github.com/clojure/clojure/commit/c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1

Attached patch with fix and test.

Comment by David Nolen [ 12/May/17 3:53 PM ]

fixed https://github.com/clojure/clojurescript/commit/d93c4356e7ab78743ae66d8cffe8df54869f0be3





[CLJS-2033] set-validator! should check current state Created: 11/May/17  Updated: 15/May/17  Resolved: 15/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2033.patch    
Patch: Code and Test

 Description   

If you set a validator on an atom, the current atom state should be checked and the validator rejected if it cannot be successfully applied to the current state. (Set the docstring for set-validator!.)

Minimal repro:

(def s (atom 1))
(set-validator! s even?)


 Comments   
Comment by David Nolen [ 15/May/17 8:05 AM ]

fixed https://github.com/clojure/clojurescript/commit/df6761abf0b2b5008956c57b8591fe1b0fa7d91c





[CLJS-2032] Case macro expansion evaluates expression twice when no matching clause Created: 10/May/17  Updated: 15/May/17  Resolved: 15/May/17

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: A. R Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2032.patch    
Patch: Code

 Description   

Related:

https://dev.clojure.org/jira/browse/CLJS-1518

The expression is still evaluated a second time when no clause matches and no default is given:

(macroexpand '(case (side-effect)
                0 1))
=>
(let*
 [G__1374682 (side-effect)]
 (case*
  G__1374682
  [[0]]
  [1]
  (throw (js/Error. (cljs.core/str "No matching clause: " (side-effect))))))

Admittedly a rare case.



 Comments   
Comment by António Nuno Monteiro [ 14/May/17 7:43 PM ]

Attached patch with fix.

Comment by David Nolen [ 15/May/17 7:53 AM ]

fixed https://github.com/clojure/clojurescript/commit/e35dd45a257b1b7bfd10e35f32a8ff0d122ae6c2





[CLJS-2031] Setting a "value" property optimized away by Closure compiler only with ClojureScript Created: 09/May/17  Updated: 10/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Jussi Nieminen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I'm compiling the following code with the latest ClojureScript compiler:

(ns repro.core)

(enable-console-print!)

(defn clear-data []
  (do
    (set! (.-value (.querySelector js/document "#data")) "")
    nil))

(.addEventListener (.querySelector js/document "#data") "keyup"
                   (fn [event]
                     (when (= (.-keyCode event) 13)
                       (clear-data))))

... which then generates a function called repro.core.clear_data, which takes care of resetting the data input field of the html page. All works fine without optimizations, but with advanced optimizations Closure decides to inline and drop the setting of the .value field. In the end I have something like this (Q.b only does comparison on its parameters):

document.querySelector("#data").addEventListener("keyup",function(a){return Q.b(a.keyCode,13),null});

The nil at the end of the "do" special form represents other stuff that gets done (this is a dumped down repro from my original code). The important thing is, that setting the property happens in the middle of the function, and the result of that operation is not returned.

Closure docs do mention that setting a property without matching reads will be considered side-effect free and thus gets dropped, but I've thought that basic property names are excluded from this. This is at least somewhat confirmed by playing with the online compiler, which does not rename a "value" property.

The code used in the link above is a de-ClojureScriptified version of the output from the ClojureScript compiler (removed the classes and goog stuff). So somehow the additional code that ClojureScript includes seems to confuse the Closure compiler's optimizations.

I'm not sure if this really is a bug, or just working as expected (if a little confusing). But decided to report it anyway just in case.



 Comments   
Comment by Thomas Heller [ 09/May/17 2:11 PM ]

I investigated something similar recently. If you compile with :closure-warnings {:check-types :warning} the set! will not be removed by Closure, but you'll get a bunch of warnings about other things.

I'm not sure why but :check-types has some effects on code removal. It is enabled by default for the Closure web app and CLI but disabled by CLJS.

Comment by Jussi Nieminen [ 10/May/17 2:26 AM ]

I can confirm that adding the above to my build config makes it work. The resulting optimized JavaScript now looks like this (linebreaks and indentation added for clarity):

document.querySelector("#data").addEventListener("keyup", function(a){
  Q.b(a.keyCode,13)&&(document.querySelector("#data").value="");
  return null
});

I do get 196 warnings for this simple piece of code though...

Comment by Thomas Heller [ 10/May/17 2:54 AM ]

You can vote for https://dev.clojure.org/jira/browse/CLJS-2019 which takes care of some of the warnings. The other part is a WIP but I can compile my work projects with :check-types enabled and get only correct warnings.

We should probably still figure out if this is intended by Closure or a bug.

Comment by A. R [ 10/May/17 2:58 AM ]

Looks like a bug in GCC:

https://github.com/google/closure-compiler/issues/2365

Adding :closure-warnings {:check-types :warning} does fix it. Presumable that's also the configuration of the online compiler.





[CLJS-2030] Case with grouped keyword test emit result-expr multiple times Created: 09/May/17  Updated: 09/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: A. R Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-2030.patch    
Patch: Code

 Description   

For case with N grouped keywords the result expression is emitted N times.

Example:

(macroexpand '(case x
                (:a :b :c :d :e) very-very-big-expr
                0))
=>
(let*
 [G__1148530 (if (cljs.core/keyword? x) (.-fqn x) nil)]
 (case*
  G__1148530
  [["a"] ["b"] ["c"] ["d"] ["e"]]
  [very-very-big-expr very-very-big-expr very-very-big-expr very-very-big-expr very-very-big-expr]
  0))

Proposed patch:

(every? core/keyword? tests)
(core/let [no-default (if (odd? (count clauses)) (butlast clauses) clauses)
                 kw-str #(.substring (core/str %) 1)
                 tests (mapv #(if (seq? %) (mapv kw-str %) [(kw-str %)]) (take-nth 2 no-default))
                 thens (vec (take-nth 2 (drop 1 no-default)))]
        `(let [~esym ~e
               ~esym (if (keyword? ~esym) (.-fqn ~esym) nil)]
           (case* ~esym ~tests ~thens ~default)))

Also fixes 2029 aka 1518.






[CLJS-2029] Case with keyword test evaluates expression twice. Created: 09/May/17  Updated: 09/May/17  Resolved: 09/May/17

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: A. R Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None


 Description   

When using case with keywords the expression is evaluated twice:

(macroexpand '(case (side-effecting-fn x)
                :a 0
                1))
=>
(let*
 [G__1143960 (if (cljs.core/keyword? (side-effecting-fn x)) (.-fqn (side-effecting-fn x)) nil)]
 (case* G__1143960 [["a"]] [0] 1))


 Comments   
Comment by A. R [ 09/May/17 8:04 AM ]

Dupe: https://dev.clojure.org/jira/browse/CLJS-1518





[CLJS-2028] `realized?` throws on LazyTransformer Created: 08/May/17  Updated: 08/May/17  Resolved: 08/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: transducers

Attachments: Text File CLJS-2028.patch    
Patch: Code and Test

 Description   

This is possible in Clojure



 Comments   
Comment by David Nolen [ 08/May/17 6:42 PM ]

fixed https://github.com/clojure/clojurescript/commit/8b409e08ddf7775299ec19c12e9421cc331838d8





[CLJS-2027] Add language-in for ECMA 2017 and ECMA Next Created: 08/May/17  Updated: 22/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Enhancement Priority: Trivial
Reporter: A. R Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-2027.patch    
Patch: Code

 Description   

GCC allows more language-in now so we can add:

(:ecmascript-2017)                CompilerOptions$LanguageMode/ECMASCRIPT_2017
    (:ecmascript-next)                CompilerOptions$LanguageMode/ECMASCRIPT_NEXT

to lang-key->lang-mode



 Comments   
Comment by António Nuno Monteiro [ 14/May/17 7:52 PM ]

This needs to wait until the Closure Compiler team releases the May 2017 version of the compiler, since the `ECMASCRIPT_2017` option was added in a recent patch: https://github.com/google/closure-compiler/pull/2453

Comment by António Nuno Monteiro [ 22/May/17 9:51 PM ]

Attached patch with fix. Also upgrades Closure to the most recent May 2017 release.





[CLJS-2026] Add Compiler option for rewrite polyfills Created: 08/May/17  Updated: 15/May/17  Resolved: 15/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: Next

Type: Enhancement Priority: Trivial
Reporter: A. R Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2026.patch    
Patch: Code

 Description   

Google closure compiler can add polyfills for the generated code. This allows users, for instance, to use native js/Promise.

(when-let [rewrite-polyfills (:rewrite-polyfills opts)]
    (.setRewritePolyfills compiler-options rewrite-polyfills))

Also needs known-opts.

It gets silently ignored unless `:language-in` is `:es6` or above. So potentially a warning would be a good idea.

There was some discussion on GCC about enabling it by default but so far have not. It is enabled by default when using the command line API of GCC.



 Comments   
Comment by António Nuno Monteiro [ 14/May/17 7:58 PM ]

Patch attached.

Comment by David Nolen [ 15/May/17 7:44 AM ]

fixed https://github.com/clojure/clojurescript/commit/2d59793ce1a5a5a0d2161fd0f887f58b9fd92f2e





[CLJS-2025] Self-host: spec tests fail Created: 07/May/17  Updated: 08/May/17  Resolved: 08/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-2025.patch    
Patch: Code and Test

 Description   

Self-host doesn't seem to be able to resolve `s/tuple` to `cljs.spec.alpha/tuple`

Looks related to automatic macro inference in self-host



 Comments   
Comment by Mike Fikes [ 08/May/17 7:53 AM ]

Confirmed that this patch doesn't break downstream Planck.

Comment by David Nolen [ 08/May/17 7:06 PM ]

fixed https://github.com/clojure/clojurescript/commit/947ccb4c45ab6ec283da6e29de94e83a56892454





[CLJS-2024] Self-host: `find-ns-obj` broken for namespaces with 'a' as the first segment Created: 07/May/17  Updated: 08/May/17  Resolved: 08/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2024.patch    
Patch: Code and Test

 Description   

Usage of js/eval triggers a weird bug where a variable named 'a' is in scope.

More context in: https://github.com/anmonteiro/lumo/issues/160



 Comments   
Comment by David Nolen [ 08/May/17 7:13 PM ]

fixed https://github.com/clojure/clojurescript/commit/6e232445e69e3e70107a8dbfe46eb9fc6a4059e2





[CLJS-2023] User supplied type hints stopped working on js/goog.DEBUG which means DCE can fail Created: 07/May/17  Updated: 15/May/17  Resolved: 15/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Mike Thompson Assignee: David Nolen
Resolution: Completed Votes: 2
Labels: None

Attachments: Text File CLJS-2023.patch    
Patch: Code and Test

 Description   

Somewhere between version 1.9.293 and 1.9.456 the type hint "^boolean" stopped working for "js/goog.DEBUG" and, as a result, this expression silently stopped being a functioning DCE guard in ":advanced" compilations.

So this code example no longer "works" (in the sense that DCE doesn't happen anymore):

(when ^boolean js/goog.DEBUG 
   ... some dev-time code in here which we want to Dead Code Eliminate at prod-time)

Note: if the guard condition is changed to use "^boolean goog.DEBUG" (no leading "js/") then it does work. So the leading "js/" is a problem.

thheller speculates that this bug arose during the introduction of :infer-externs
https://github.com/clojure/clojurescript/commit/0560106fe8576fd7029d86e61be09cd1f246bfe0

Some discussion in slack:
https://clojurians-log.clojureverse.org/cljs-dev/2017-05-04.html

I have created a minimal repo which demonstrates the problem:
https://github.com/mike-thompson-day8/CLJS-issue-2023



 Comments   
Comment by Thomas Heller [ 07/May/17 7:08 AM ]

This can be reproduced by running cljs.analyzer.api/analyze on (with-meta 'js/goog.DEBUG {:tag 'boolean}).

{:form ^boolean js/goog.DEBUG,
 :op :var,
 :info
 {:name ^boolean js/goog.DEBUG,
  :ns js,
  :tag ^{:prefix [goog DEBUG]} js},
 :tag ^{:prefix [goog DEBUG]} js}

Running a quick git bisect the :tag changed from boolean to js in this commit:
https://github.com/clojure/clojurescript/commit/0560106fe8576fd7029d86e61be09cd1f246bfe0

Comment by António Nuno Monteiro [ 14/May/17 8:13 PM ]

Attached patch with fix and test.

Comment by David Nolen [ 15/May/17 7:27 AM ]

fixed https://github.com/clojure/clojurescript/commit/123643b1821a415c104a8432b5e4dc033644ef98





[CLJS-2022] cljs.spec -> cljs.spec.alpha fixes Created: 05/May/17  Updated: 05/May/17  Resolved: 05/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2022.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 05/May/17 6:11 PM ]

fixed https://github.com/clojure/clojurescript/commit/cf617c8d4594efd061954c3df3d9e96dacefdb21





[CLJS-2021] Passing a non-vector to subvec returns an unusable object Created: 02/May/17  Updated: 12/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Frank Wang Assignee: David Nolen
Resolution: Unresolved Votes: 5
Labels: None

Attachments: Text File CLJS-2021.patch    

 Description   

For (subvec v start end), v can be any data type so long as (and (<= end (count v)) (<= start (count v))) is true. If v does not satisfy IVector, performing vector operations on the returned object will result in unexpected behaviour.

For example:

cljs.user=> (def subvec-list (subvec '(:foo) 0 1))
#'cljs.user/subvec-list
cljs.user=> (conj subvec-list :bar)
Error: No protocol method IVector.-assoc-n defined for type cljs.core/List: (:foo)

cljs.user=> (def subvec-nil (subvec nil 0 0))
#'cljs.user/subvec-nil
cljs.user=> subvec-nil
[]
cljs.user=> (conj subvec-nil :bar)
Error: No protocol method IVector.-assoc-n defined for type null:

cljs.user=> (def subvec-nil' (assoc subvec-nil 0 :foo))
#'cljs.user/subvec-nil'
cljs.user=> subvec-nil'
#object[Error Error: No protocol method IIndexed.-nth defined for type cljs.core/PersistentHashMap: {0 :foo}] cljs.user=> (def subvec-map (subvec {:foo :bar} 0 1))

#'cljs.user/subvec-map
cljs.user=> (assoc subvec-map :some-key :some-val)
Error: Subvec's key for assoc must be a number.
cljs.user=> (assoc subvec-map 0 :some-val)
#object[Error Error: No protocol method IIndexed.-nth defined for type cljs.core/PersistentArrayMap: {:foo :bar, 0 :some-val}]

This behaviour is inconsistent with JVM Clojure, where subvec will throw if (not (vector? v)).



 Comments   
Comment by Frank Wang [ 02/May/17 1:20 PM ]

A workaround for this is to call vec on the data structure before passing it to subvec.





[CLJS-2020] defmulti "miss" performance poor Created: 02/May/17  Updated: 15/May/17  Resolved: 15/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Enhancement Priority: Minor
Reporter: Oliver George Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2020.patch    
Patch: Code

 Description   

I'm seeing a performance problem with clojurescripts defmulti:

  • dispatch is slow when there is no match for the dispatch value
  • slowness increases as the method-table grows ~O

Verified with optimisations :none and :advanced.

Verified not to be an issue for Clojure on JVM.

Example 1: Dispatch and hit
(do (defmulti exp1 :type)
    (defmethod exp1 :default [x] x)
    (dotimes [n 100] (defmethod exp1 n [x] x))
    (time (dotimes [n 100] (exp1 {:type :default}))))

"Elapsed time: 0.390000 msecs"
Example 2: Dispatch and miss
(do (defmulti exp2 :type)
    (defmethod exp2 :default [x] x)
    (dotimes [n 100] (defmethod exp2 n [x] x))
    (time (dotimes [n 100] (exp2 {:type :miss}))))

"Elapsed time: 72.530000 msecs"
Example 3: More methods (x10)
(do (defmulti exp3 :type)
    (defmethod exp3 :default [x] x)
    (dotimes [n 1000] (defmethod exp3 n [x] x))
    (time (dotimes [n 100] (exp3 {:type :miss}))))

"Elapsed time: 475.145000 msecs"


 Comments   
Comment by Oliver George [ 02/May/17 5:53 PM ]

I think this affects a common use case: using defmulti as an extension point but rely on default behaviour most of the time.

Comment by António Nuno Monteiro [ 14/May/17 9:13 PM ]

Attached patch with fix. The patch applies the same changes that were applied to Clojure in the following commit: https://github.com/clojure/clojure/commit/6d305a0959183acb75fc44f9192eed2abf33bf25. Benchmarks of before and after in my machine are shown below.

Example | Before | After
1 | 2.642308 msecs | 3.099353 msecs
2 | 72.614162 msecs | 7.423098 msecs
3 | 212.955697 msecs | 19.691014 msecs

Comment by David Nolen [ 15/May/17 6:44 AM ]

fixed https://github.com/clojure/clojurescript/commit/957cb8756f5a4b71bcc96d0d08943c83242dccfc





[CLJS-2019] Some code is generated with invalid arities Created: 30/Apr/17  Updated: 12/May/17  Resolved: 12/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: David Nolen
Resolution: Completed Votes: 2
Labels: None

Attachments: Text File check-types-warnings.patch    
Patch: Code

 Description   

I'm currently working on some Closure :check-types related things and this uncovered a few code generation issues where some invalid function calls are generated. The cljs.compiler/checking-types? also checked for :warn but :warning is the correct value.

Off by one (missing meta)

-                      (emitln restarg " = new cljs.core.IndexedSeq(" a ",0);"))
+                      (emitln restarg " = new cljs.core.IndexedSeq(" a ",0,null);"))
(deftype IndexedSeq [arr i meta] ...)

Off by one: undeclared argument

-      :else (emits "cljs.core.PersistentHashSet.createAsIfByAssoc([" (comma-sep items) "], true)"))))
+      :else (emits "cljs.core.PersistentHashSet.createAsIfByAssoc([" (comma-sep items) "])"))))
(set! (.-createAsIfByAssoc PersistentHashSet)
      (fn [items] ...

Off by two: undeclared arguments

-    (.createAsIfByAssoc PersistentArrayMap arr true false)))
+    (.createAsIfByAssoc PersistentArrayMap arr)))
(set! (.-createAsIfByAssoc PersistentArrayMap)
  (fn [arr] ...


 Comments   
Comment by David Nolen [ 12/May/17 1:48 PM ]

fixed https://github.com/clojure/clojurescript/commit/f94831627e8795a93937b97b5b6fe739e0280167





[CLJS-2018] User supplied externs not loaded with user specified compiler state Created: 25/Apr/17  Updated: 26/Apr/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Jonathan Henry Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-2018.patch    

 Description   

User supplied externs for use with warn-on-infer are only loaded in the 2-arity versions of cljs.closure/build, cljs.build.api/build and cljs.build.api/watch when compiler is nil.

Note: This only affects the warnings that are generated by the analyzer with warn-on-infer; the externs are correctly passed to gclosure.



 Comments   
Comment by Jonathan Henry [ 25/Apr/17 7:34 PM ]

This patch moves the loading of externs from cljs.env/default-compiler-env to cljs.closure/build.

Comment by Jonathan Henry [ 26/Apr/17 12:20 PM ]

Ignore this patch, I just realized this makes it so the built-in externs are no longer loaded for the compiler and analyzer API.





[CLJS-2017] Upgrade Closure Compiler to latest April 2017 release Created: 25/Apr/17  Updated: 28/Apr/17  Resolved: 28/Apr/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: closure

Attachments: Text File CLJS-2017.patch    
Patch: Code

 Description   

The Closure Compiler team has released a new version that includes more enhancements to JS module processing



 Comments   
Comment by David Nolen [ 28/Apr/17 3:11 PM ]

fixed https://github.com/clojure/clojurescript/commit/c488bfed8d050d9825a7407dfc4bb813e2cdda85





[CLJS-2016] Support inheritance annotations in externs Created: 25/Apr/17  Updated: 25/Apr/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Jonathan Henry Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Closure externs may contain @extends annotations to specify base classes. The base classes' attributes should be propagated to subclasses in `:cljs.analyzer/externs`.






[CLJS-2015] Self-host: `defmacro` should return the Var Created: 24/Apr/17  Updated: 28/Apr/17  Resolved: 28/Apr/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-2015.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 28/Apr/17 3:30 PM ]

fixed https://github.com/clojure/clojurescript/commit/3c0c775b8c731806765d425781d0bfd16c0d7f51





[CLJS-2014] find on sorted-map entries broken Created: 19/Apr/17  Updated: 05/May/17  Resolved: 05/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

The entries of a sorted-map no longer behave as expected when find is called on them.

cljs.user=> (find (first (sorted-map :key :val)) 0)
[:key :val]
; expected [0 :key]
cljs.user=> (find (first (sorted-map :key :val)) 1)
[:key :val]
; expected [1 :val]


 Comments   
Comment by Thomas Mulvaney [ 05/May/17 3:01 PM ]

Fixed in CLJS-2013





[CLJS-2013] Add MapEntry type Created: 19/Apr/17  Updated: 05/May/17  Resolved: 05/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Thomas Mulvaney Assignee: Thomas Mulvaney
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2013.1.patch     Text File CLJS-2013.patch    
Patch: Code and Test

 Description   

It would be nice to have a MapEntry type in ClojureScript.

Since the introduction of the map-entry? predicate in Clojure 1.8 it has been trivial to determine if an object represents an entry in a map. Being able to distinguish a map entry from other data types is really handy when walking data amongst other things. Currently, ClojureScript uses PersistentVectors to represent entries from PersistentArrayMaps and PersistentHashMaps. PersistentTreeMaps use their own nodes to represent entries and as such would be unaffected.

Besides making it possible to use the the map-entry? predicate across both CLJ and CLJS code, there may space/performance benefits to having a specialised type.



 Comments   
Comment by Thomas Mulvaney [ 26/Apr/17 11:05 AM ]

I've attached a patch which introduces the MapEntry type. It's there but not hooked up - PAMs and PHMs don't emit them when you `seq` or `iterate` over them yet.

There is a set of tests which check the protocols all map entries should implement: IVector, IAssociative, ISeq etc. The exact same set of tests are run across PersistentVector, RedNode, BlackNode and the new MapEntry type to ensure they behave identically.

A few bugs were caught in doing so:

  • -nth on RedNodes and BlackNodes with an out of bounds index did not throw an exception.
  • -invoke with an out of bounds index had the same problem
  • -find behaviour on Red and Black nodes did not behave as expected. See CLJS-2014
  • PersistentVectors, RedNodes and BlackNodes all implement IAssociative but missed the -contains-key? method.

The listed bugs were fixed in the patch.

Comment by David Nolen [ 28/Apr/17 3:06 PM ]

This patch appears broken. When I try to run the tests I get exception about `cond` having a non-even number of forms.

Comment by Thomas Mulvaney [ 28/Apr/17 3:58 PM ]

Yep, looks like I messed that up squashing/cleaning up commits, sorry. Fixed patch attached.

Comment by David Nolen [ 05/May/17 12:31 PM ]

fixed https://github.com/clojure/clojurescript/commit/78891af8b68899e0e0456161116aeab23d1c031a





[CLJS-2012] find on PHM with nil entry always returns nil entry Created: 19/Apr/17  Updated: 11/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-2012.patch    
Patch: Code and Test

 Description   

The following always returns the nil entry:

(find (hash-map :a 1 :b 2 nil 3) :a) 
; [nil 3]


 Comments   
Comment by Francis Avila [ 19/Apr/17 10:11 AM ]

The way -find is called, it is guaranteed that (contains? coll k) was called and returned true first; -find is never responsible for membership testing. So the has-nil? is unnecessary. This would be a sufficient impl/patch:

(-find [coll k]
  (if (nil? k)
    [nil nil-val]
    (.inode-find root 0 (hash k) k nil)))

Now, whether this should be the contract for -find is a different story. We could potentially avoid double-lookup if -find were also responsible for membership testing: collections where testing membership also happens to retrieve the value could avoid doing it twice.

Comment by Thomas Mulvaney [ 19/Apr/17 10:19 AM ]

Yes, that is a much nicer patch. The current double lookup implementation of find is probably at its worst with PersistentTreeMaps which I think are O(log2n) rather than log32 like PHMs.

Comment by Thomas Mulvaney [ 11/May/17 7:10 AM ]

From what I understand IFind.-find takes the place of the IAssociative.entryAt method in Clojure. In Clojure from what I can tell, find makes a call to entryAt rather than doing a double lookup. Indeed, there is a commented out -entry-at method in Clojurescripts declaration of the IAssociative protocol. Does following the behaviour of entryAt in Clojure makes sense?





[CLJS-2011] :modules cannot rely on code motion or dead code removal Created: 19/Apr/17  Updated: 06/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Currently the :modules compiler option relies on code motion and dead code removal by the Closure Compiler. Many constructs used by CLJS are not moved/removed by Closure so the result will very likely be sub-optimal.

Summary

:modules currently relies on code motion and the user specifying every namespace that should go into a module.

This is unlikely to produce good results and several things are not correctly identified as pure by Closure and therefore are not moved.

Namespaces that are not referenced by any of the configured :entries are still included in the cljs_base.js module. If these files contain any kind of side-effects they are not removed as well.

Problematic issues include defmethod, anything with ^:export, construction of hash maps and more.

The :optimize-constants implicit option of :advanced is also not optimal and every keyword ends up in the cljs_base.js module.

Examples

Given this demo repo: https://github.com/thheller/cljs-issues/tree/master/modules

With the following ns structure:

  • foo.main requires foo.a, contains kw :foo.main/main
  • foo.a contains kw :foo.a/a
  • foo.b contains kw :foo.b/b and is not required by anything.

Built with these options:

(cljs/build
  "src"
  {:modules
   {:main
    {:entries ['foo.main]
     :output-to "out/main.js"}}
   :output-dir "out"
   :verbose true
   :optimizations :advanced})

The following build output:

Building module :cljs-base
Building module :main
  adding entry (foo.main)
  module :main depends on :cljs-base
Adding remaining namespaces to :cljs-base
  adding entry (goog)
  adding entry [goog.string goog.string.Unicode]
  adding entry [goog.object]
  adding entry [goog.math.Integer]
  adding entry [goog.string.StringBuffer]
  adding entry [goog.debug.Error]
  adding entry [goog.dom.NodeType]
  adding entry [goog.asserts goog.asserts.AssertionError]
  adding entry [goog.array]
  adding entry [goog.reflect]
  adding entry [goog.math.Long]
  adding entry (cljs.core)
  adding entry (cljs.core.constants)
  adding entry (foo.b)
  adding entry (foo.a)
  • foo.b was never referenced and should not have been included in the build.
  • foo.a was only used by foo.main but ended up in the cljs_base.js module since it is a transitive dependency the user did not specify. It should have been in the :main module before going into Closure.
  • main.js only contains something like console.log("main loaded",Fe); where Fe is the keyword which was constructed in the cljs_base.js although it was only used in this module.

A similar example at https://github.com/kommen/cljs-issues/tree/modules-foreign-libs/modules adds a dependency from foo.a to cljsjs.plotly

Build output:

Building module :cljs-base
Building module :main
  adding entry (foo.main)
  module :main depends on :cljs-base
Adding remaining namespaces to :cljs-base
  adding entry (goog)
  adding entry [goog.string goog.string.Unicode]
  adding entry [goog.object]
  adding entry [goog.math.Integer]
  adding entry [goog.string.StringBuffer]
  adding entry [goog.debug.Error]
  adding entry [goog.dom.NodeType]
  adding entry [goog.asserts goog.asserts.AssertionError]
  adding entry [goog.array]
  adding entry [goog.reflect]
  adding entry [goog.math.Long]
  adding entry (cljs.core)
  adding entry (cljs.core.constants)
  adding entry [cljsjs.plotly]
  adding entry (foo.a)
  adding entry (foo.b)
  • cljsjs.plotly was only used in foo.a, which itself is only used in foo.main, but ended up in cljs_base.js


 Comments   
Comment by David Nolen [ 28/Apr/17 3:59 PM ]

I don't see how this is a problem at all. This is just expected?

Comment by Thomas Heller [ 28/Apr/17 5:59 PM ]

This is not expected at all.

I assume you read the README of the demo project which highlighted some of the problems? I really don't know how to explain this better.

In shadow-build I collect the dependencies of all defined :entries and then move them as close to the edges as possible. If a dependency is only used in one :module it will be in that :module and not the base module. In my work project I define ONE entry namespace for one module and that causes 55 other files to be moved there as well. You really shouldn't expect a user to specify all 56 namespaces to get a proper split.

These files contain defmethod, cljs.spec/def and other side-effecty things that will not be moved by code-motion. They would remain in the base module. The solution is to add the files to the Closure JSModule before calling compile, which also allows :modules to work reasonably well in :simple and :whitespace.

Files that aren't required anywhere should not be passed into Closure as it cannot be guaranteed that they will be removed.

Comment by Dieter Komendera [ 03/May/17 7:57 AM ]

I'm also running into issues where :modules doesn't work as expected for me.

I've pushed a fork of Thomas' demo repo here showing that a dependency which I would expect to be moved into the main module, but instead it is put into the cljs_base module.

https://github.com/kommen/cljs-issues/tree/modules-foreign-libs/modules

Comment by David Nolen [ 05/May/17 12:21 PM ]

Thomas, I'm not going to look at information not in a ticket sorry. If there are details you want to be considered put them into the issue. This issue is danger of being closed unless corrected. Thanks.

Comment by Francis Avila [ 05/May/17 6:27 PM ]

I have updated the ticket description to include text from the READMEs mentioned in the two linked repositories. The code to reproduce the builds is too large to attach, so see linked repos for details.

Comment by Thomas Heller [ 06/May/17 2:45 AM ]

Francis Avila: Thanks for updating the description!

David Nolen: Sorry for keeping the description in the github repo, didn't think that this would be a problem. I mentioned these issues when you implemented :modules but that got lost in chat archives.

My only interest here was to report it so "someone" would hopefully pick it up. I can't take this any further as I disagree with some other related implementation choices.





[CLJS-2010] refer-clojure :rename throws on valid invocations Created: 18/Apr/17  Updated: 28/Apr/17  Resolved: 28/Apr/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: analyzer

Attachments: Text File CLJS-2010.patch    
Patch: Code and Test

 Comments   
Comment by David Nolen [ 28/Apr/17 4:08 PM ]

https://github.com/clojure/clojurescript/commit/9dafe7d87a4b4a387a82fce9e3a0d63bbe565e4f





[CLJS-2009] Remove unnecessary code introduced by CLJS-1973 Created: 14/Apr/17  Updated: 14/Apr/17  Resolved: 14/Apr/17

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2009.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 14/Apr/17 11:22 AM ]

fixed https://github.com/clojure/clojurescript/commit/b79e45a706201087f69df56647055c442dca7229





[CLJS-2008] Self-host: backport fixes to threading macros Created: 13/Apr/17  Updated: 15/May/17  Resolved: 15/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Christophe Grand Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-2008.patch    
Patch: Code and Test

 Description   

Backport the fix for CLJ-1562 and CLJ-1418 (commit https://github.com/clojure/clojure/commit/5e655b5b12bde5d2b1434b82b1ed445815ea9a95)



 Comments   
Comment by David Nolen [ 15/May/17 8:01 AM ]

fixed https://github.com/clojure/clojurescript/commit/1ed7091056324d5bed26bbf1e317e1cbaeaee008





[CLJS-2007] :main namespace silently ignored under :whitespace optimizations Created: 12/Apr/17  Updated: 28/Apr/17  Resolved: 28/Apr/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Kevin Lynagh Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: compiler
Environment:

cljs.jar 1.9.473. Full reproducible example at https://github.com/lynaghk/reproducible-reports/tree/master/1-main-option


Attachments: Text File CLJS-2007.patch    
Patch: Code

 Description   

The ClojureScript compiler's :main option specifies an "entry point namespace". In the output JavaScript, I expect the compiler to include only the entry point namespace, and the transitive closure of namespaces required by that namespace.

However, in ClojureScript r1.9.473, the :main is silently ignored when :optimizations :whitespace is set.

As a user, my expectation is that the whitespace optimizations case would act the same as the simple optimizations case.

If this is not possible, I think the compiler should throw an error when the :main option is provided together with :optimizations :whitespace to prevent confusion / frustration.
(Ditto for behavior under :optimizations :none)

I'm happy to contribute a patch for whatever behavior the core team deems preferable.

Thanks

Kevin



 Comments   
Comment by David Nolen [ 28/Apr/17 4:01 PM ]

fixed https://github.com/clojure/clojurescript/commit/837aeaf87b3b6eb7c6a48a12c699c98a21ecec37





[CLJS-2006] Upgrade Closure Compiler to April 2017 release Created: 11/Apr/17  Updated: 12/Apr/17  Resolved: 12/Apr/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Enhancement Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: None

Attachments: Text File CLJS-2006.patch    
Patch: Code

 Comments   
Comment by António Nuno Monteiro [ 11/Apr/17 6:12 PM ]

Patch attached to upgrade the version of Google Closure Compiler. This version also contains the fix for CLJS-1954.

Comment by David Nolen [ 12/Apr/17 1:04 PM ]

fixed https://github.com/clojure/clojurescript/commit/3a9e4b43a2c01be5ed8945b2a90d04dcd14af1c2





[CLJS-2005] Bad error message with duplicate arity function definitions. Created: 10/Apr/17  Updated: 15/May/17  Resolved: 15/May/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Russ Olsen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

MacOS X
Clojure 1.9.0-master-SNAPSHOT
Java HotSpot(TM) 64-Bit Server VM 1.8.0_65-b17

Also Lumo


Attachments: Text File CLJS-2005.patch    
Patch: Code and Test

 Description   

If you write a multi-arity function with duplicate arities, like this:

(defn myfun ([x] x) ([x] x))

You get a very uninformative error message from the cljs compiler:

Duplicate case test constant '1' on line 1 at line 1

The JVM compiler produces a much clearer error message:

CompilerException java.lang.RuntimeException: Can't have 2 overloads with same arity,...



 Comments   
Comment by António Nuno Monteiro [ 14/May/17 9:46 PM ]

Attached patch with fix and test.

Comment by David Nolen [ 15/May/17 7:57 AM ]

fixed https://github.com/clojure/clojurescript/commit/be518275ec0590693ebdcb976cbe4cd8a6cef732





[CLJS-2004] Minor fix for test-simple script Created: 10/Apr/17  Updated: 14/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Dejan Josifovic Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: clojurescript, script, test
Environment:

Lubuntu 16.10


Attachments: Text File CLJS-2004.patch    
Patch: Code

 Description   

On Ubuntu based Linux distributions $[] doesn't work.
Output is: Tested with $[ran+1] out of 4 possible js targets
and should be: Tested with 4 out of 4 possible js targets

As in CLJS-929 (for test script), $(()) will work for ash, dash, bash, and zsh.



 Comments   
Comment by Dejan Josifovic [ 10/Apr/17 2:42 PM ]

Add patch.





[CLJS-2003] munge/demunge in cljs.core has too many calls to str Created: 10/Apr/17  Updated: 14/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Erik Assum Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-CLJS-2003-remove-redundant-calls-to-str-in-munge-dem.patch    
Patch: Code




[CLJS-2002] Don't throw when no *print-fn* is set Created: 07/Apr/17  Updated: 07/Apr/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Currently calling (enable-console-print!) causes a bunch of code to be retained in :advanced mode even if you never print.

While that is not ideal it doesn't cause runtime errors. Not calling it and trying to print however will throw an exception which will potentially break your app.

No *print-fn* fn set for evaluation environment

So we end up in a no-win situation for :advanced builds where a "forgotten" prn may break your app in production or "maybe" bloating your file size by retaining all the print-related things.

I think the no-print-fn condition should never throw, maybe just try to write a warning using console.log. Or just dropping the prn altogether.






[CLJS-2001] Add map-entry? predicate Created: 06/Apr/17  Updated: 19/Apr/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-2001.patch    
Patch: Code and Test

 Description   

map-entry? has existed in Clojure since 1.8 would be nice to have it in ClojureScript.



 Comments   
Comment by Thomas Mulvaney [ 06/Apr/17 6:00 AM ]

The attached patch looks more like the first implementation of `map-entry?` as per CLJ-1831.

This is because ClojureScript returns PersistentVectors when iterating over PAM and PHM maps.

Comment by David Nolen [ 07/Apr/17 11:06 AM ]

This patch is no good. 2 element vectors are not MapEntry.

Comment by Francis Avila [ 07/Apr/17 7:22 PM ]

Given that Clojure still returns MapEntry (CLJ-1831 was backed out later) and CLJS returns vectors, it is probably impossible for this predicate to be portable. If we can't consider count-2 vectors map-entry?=true, then the only possible cljs impl is (defn map-entry? [x] false). Given this, perhaps the best solution is not to have map-entry? in cljs, to discourage people from using it in portable code.

Comment by David Nolen [ 12/Apr/17 1:03 PM ]

I'm fine with adding a MapEntry type which implements all the vector protocols and returning that instead. That work should be a separate issue though and then we can come back to this one.

Comment by Thomas Mulvaney [ 19/Apr/17 8:00 AM ]

This came about as I was porting some Clojure code. I was probably misusing/abusing map-entry? anyway. The code could be rewritten to check if something is a map first and then do the appropriate thing on the sequence of entries rather than doing the check from "with in" the collection.

As mentioned, a 2 element vector != MapEntry. So, I've opened an issue to track adding a MapEntry type: CLJS-2013





[CLJS-2000] Don't log deprecation warnings on recursive calls to the same function with a different arity Created: 05/Apr/17  Updated: 06/Apr/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Daniel Compton Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: warning


 Description   

If a function has two arity's where one calls the other, then if that function is marked with `^:deprecated`, then compile warnings about deprecations will always be emitted while that function exists. E.g.

(defn ^:deprecated test-deprecated
  ([]
    (test-deprecated nil))
  ([a]
    nil))

produces these logs:

WARNING: my.test/test-deprecated is deprecated. at line 3 src/my/test/error.cljs

I think that only outside references to a deprecated function should warn here. Otherwise, it's impossible to deprecate a multi-arity function and still get clean compiles.






[CLJS-1999] Nullpointer Exception while compiling node module Created: 05/Apr/17  Updated: 05/Apr/17  Resolved: 05/Apr/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: Next
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Daniel Große Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug, compiler
Environment:

MacOSX 10.11.6
Node 7.8.0
npm 4.5.0



 Description   

While trying the compilation of an node module, I got an exception thrown.

monospaced
lein cljsbuild once  1 ↵  2506  16:17:41
Compiling ClojureScript.
Compiling "resources/autobahn_cljs.js" from ["src"]...
Compiling "resources/autobahn_cljs.js" failed.
java.lang.NullPointerException
at com.google.javascript.jscomp.ProcessCommonJSModules.getScopeInsertionPoint(ProcessCommonJSModules.java:242)
at com.google.javascript.jscomp.ProcessCommonJSModules.access$400(ProcessCommonJSModules.java:42)
at com.google.javascript.jscomp.ProcessCommonJSModules$FindImportsAndExports.addGoogProvide(ProcessCommonJSModules.java:556)
at com.google.javascript.jscomp.ProcessCommonJSModules.process(ProcessCommonJSModules.java:125)
at com.google.javascript.jscomp.Compiler.processAMDAndCommonJSModules(Compiler.java:1841)
at com.google.javascript.jscomp.Compiler.parseInputs(Compiler.java:1549)
at com.google.javascript.jscomp.Compiler.parse(Compiler.java:809)
at cljs.closure$eval5980$fn__5981.invoke(closure.clj:1601)
at clojure.lang.MultiFn.invoke(MultiFn.java:238)
at cljs.closure$process_js_modules$fn__6251.invoke(closure.clj:2156)
at clojure.core$map$fn__4785.invoke(core.clj:2646)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:521)
at clojure.core$seq__4357.invokeStatic(core.clj:137)
at clojure.core$apply.invokeStatic(core.clj:641)
at clojure.core$mapcat.invokeStatic(core.clj:2674)
at clojure.core$mapcat.doInvoke(core.clj:2674)
at clojure.lang.RestFn.invoke(RestFn.java:423)
at cljs.closure$process_js_modules.invokeStatic(closure.clj:2155)
at cljs.closure$process_js_modules.invoke(closure.clj:2127)
at cljs.closure$build.invokeStatic(closure.clj:2229)
at cljs.closure$build.invoke(closure.clj:2216)
at cljs.closure$build.invokeStatic(closure.clj:2219)
at cljs.closure$build.invoke(closure.clj:2216)
at cljsbuild.compiler$compile_cljs$fn__6424.invoke(compiler.clj:81)
at cljsbuild.compiler$compile_cljs.invokeStatic(compiler.clj:80)
at cljsbuild.compiler$compile_cljs.invoke(compiler.clj:69)
at cljsbuild.compiler$run_compiler.invokeStatic(compiler.clj:187)
at cljsbuild.compiler$run_compiler.invoke(compiler.clj:143)
at user$eval6558$iter_65946598$fn6599$fn_6617.invoke(form-init8848799542314272754.clj:1)
at user$eval6558$iter_65946598$fn_6599.invoke(form-init8848799542314272754.clj:1)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:521)
at clojure.core$seq__4357.invokeStatic(core.clj:137)
at clojure.core$dorun.invokeStatic(core.clj:3024)
at clojure.core$doall.invokeStatic(core.clj:3039)
at clojure.core$doall.invoke(core.clj:3039)
at user$eval6558.invokeStatic(form-init8848799542314272754.clj:1)
at user$eval6558.invoke(form-init8848799542314272754.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.eval(Compiler.java:6917)
at clojure.lang.Compiler.load(Compiler.java:7379)
at clojure.lang.Compiler.loadFile(Compiler.java:7317)
at clojure.main$load_script.invokeStatic(main.clj:275)
at clojure.main$init_opt.invokeStatic(main.clj:277)
at clojure.main$init_opt.invoke(main.clj:277)
at clojure.main$initialize.invokeStatic(main.clj:308)
at clojure.main$null_opt.invokeStatic(main.clj:342)
at clojure.main$null_opt.invoke(main.clj:339)
at clojure.main$main.invokeStatic(main.clj:421)
at clojure.main$main.doInvoke(main.clj:384)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Subprocess failed
monospaced

A demo repository can be found under: https://github.com/Ninerian/npm-compile-test



 Comments   
Comment by António Nuno Monteiro [ 05/Apr/17 10:06 AM ]

This is not a clojureScript issue. It's fixed in Closure Compiler master and we're waiting on a new release. Relevant issue: https://github.com/google/closure-compiler/issues/2345





[CLJS-1998] Printing an Object with a null prototype throws an error Created: 04/Apr/17  Updated: 13/Apr/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Jonathan Boston Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

ClojureScript doesn't handle printing objects with a null prototype:

(prn (.create js/Object nil)) ;;throws Uncaught TypeError: Cannot read property 'cljs$lang$ctorStr' of undefined
(str (.create js/Object nil)) ;;throws Uncaught TypeError: Cannot convert object to primitive value

For the first case, it looks like pr-writer-impl's last case needs a separate check for a nil object constructor. I've not yet investigated the second case.



 Comments   
Comment by David Nolen [ 07/Apr/17 11:09 AM ]

Is this a common JS pattern?

Comment by Jonathan Boston [ 07/Apr/17 11:40 AM ]

I assume it isn't since I only recently ran into it. But PDFjs uses it regularly, which is where the problem came to light.

It appears to be used for objects that are strictly for wrapping other data. Perhaps it's a performance optimization?

I'm away from a computer for the next few days, but can provide links/more info then as necessary.

Comment by David Nolen [ 07/Apr/17 12:03 PM ]

I'm happy to see a fix for the first case and I'd like hear more information about the second one.

Comment by Jonathan Boston [ 13/Apr/17 2:05 AM ]

So the second case is interesting and I'm not sure of the fix implications. The following plain javascript highlights the problem:

Object.create(null) + "";
"" + Object.create(null);
[Object.create(null)].join(""); //str implementation uses this

//all three calls give the following error
Uncaught TypeError: Cannot convert object to primitive value

The str implementation passes the value through to array.join, so we'd need to check for null prototypes for every str call.

Adding an extra conditional to printing out to the console seems harmless enough, but adding an extra conditional for every str call seems like it might not be worth it.

I'm happy to do a fix for whatever you suggest.





[CLJS-1997] Outward function type hint propagation Created: 03/Apr/17  Updated: 07/Apr/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File CLJS-1997.patch    

 Description   

New feature: Detect the type of a function and arrange so that it is available for outward type hinting.

For reference, a small amount of discussion from Jan 2016 in the #cljs-dev Slack:

mfikes: Curious if "outward" ^boolean propagation has been debated / rejected. Example: If simple analysis detects that ^boolean can be applied as in for functions like (defn f [x] (not x)). Perhaps automatically propagating type hints in this direction would be unwelcome by users?

dnolen: @mfikes: we have already have outward propagation for numerics which broke because of changes for code motion

dnolen: absolutely nothing against that



 Comments   
Comment by Mike Fikes [ 03/Apr/17 7:38 PM ]

The attached patch will handle cases like

(defn foo? [x] (or (string? x) (number? x)))

and

(def baz (fn ([x] 1) ([x y] 2)))

but it doesn't attempt to address the case of multi-arity defn s, as these are implemented by dispatching to multiple single-arity functions that could have different return types.

It adds a :inferred-ret-tag to the AST only because the arguments to or on line 18 in the patch are not reversed (only to allow explicit hints to override inferred hints, but perhaps that is overcomplicating things and the inferred tag could be dropped directly into :ret-tag.)

Bronsa helpfully pointed out in Slack that outward type hint propagation is avoided in Clojure because it breaks things like:

(defn foo [] 1)
(defn bar [] (String/valueOf (foo)))
(defn foo [] "foo")
(bar)

for which an analogy in ClojureScript would be:

(defn foo? [] true)
(defn bar [] (if (foo?) :t :f))
(defn foo? [] "")
(bar)

where the patch causes it to yield :f.

This could be viewed as a REPL-only concern (perhaps addressed by another compiler flag along the lines of :static-fns).

But, arguably the problem already exists today, with type hinting in code like the following affecting the compilation of bar:

(def foo? true)
(defn bar [] (if foo? :t :f))
(def foo? "")
(bar)
Comment by David Nolen [ 07/Apr/17 11:15 AM ]

Thanks will think about it





[CLJS-1996] Support correct checking of :preloads when :optimizations not specified Created: 03/Apr/17  Updated: 07/Apr/17  Resolved: 07/Apr/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Trivial
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1996.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 07/Apr/17 11:16 AM ]

fixed https://github.com/clojure/clojurescript/commit/79509651e16bf2b2fdc60a39de8671ef96206055





[CLJS-1995] Possible conflict with automatic aliases for JS modules Created: 02/Apr/17  Updated: 02/Apr/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

https://clojurescript.org/guides/javascript-modules

The hello-es6 example uses a directory to apply :module-type to every file in that directory.

{:file "src" :module-type :es6}

This leads to src/js/hello.js being aliased to the js.hello ns which .cljs files can then :require.

Given a directory structure like this:

{:file "lib-a" :module-type :es6}
{:file "lib-b" :module-type :es6}

.
├── lib-a
│   └── js
│       └── hello.js
├── lib-b
│   └── js
│       └── hello.js

Leads to lib-b silently replacing lib-a as they both claim the js.hello name.

The same issue is present in closure-compliant libs but they typically follow some kind of manual namespacing (ie. goog.string, cljs.core, ...) which ES6/JS libs do not do (and do not even support given their use of relative imports vs absolute imports)

Not sure how to handle this but at the very least there should be some kind of warning that there is a conflicting alias.

Demo here: https://github.com/thheller/hello-es6-conflict






[CLJS-1994] assoc on nil returns PHM (expected PAM) Created: 01/Apr/17  Updated: 07/Apr/17  Resolved: 07/Apr/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1994.patch    

 Description   

(assoc nil :foo 1) results in a PersistentHashMap in CLJS but a PersistentArrayMap in CLJ.



 Comments   
Comment by Thomas Heller [ 04/Apr/17 2:11 AM ]

Updated patch to address warning about undeclared cljs.lang.PersistentArrayMap.

Comment by David Nolen [ 07/Apr/17 11:13 AM ]

fixed https://github.com/clojure/clojurescript/commit/b35d693582db4fea39fa10bf0359b4055e8f4125





[CLJS-1993] cljs.spec: form of cljs.spec/every is broken Created: 31/Mar/17  Updated: 31/Mar/17  Resolved: 31/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Tommi Reiman Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Environment:

tested with 1.9.494 (the dropdown doesn't allow that)



 Description   

Trying to generate JSON Schemas out of Specs using forms and bumped into this:

cljs.spec/every produces broken form. This is how it looks on the Clojure (1.9.0-alpha15) side:

(s/form (s/every integer?))
; => (clojure.spec/every clojure.core/integer?)

This the ClojureScript version:

(s/form (s/every integer?))
; (cljs.spec/every integer? :cljs.spec/kind-form nil :cljs.spec/cpred #object[Function "function (G__19233){
; return cljs.core.coll_QMARK_.call(null,G__19233);
; }"])


 Comments   
Comment by António Nuno Monteiro [ 31/Mar/17 9:22 AM ]

This is solved in master





[CLJS-1992] declare after def should have no effect Created: 30/Mar/17  Updated: 13/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-1994.patch    

 Description   

Currently using declare after def will override all the analyzer data of the def with the basically empty data of the declare

(ns test.declare-after-def)

(defn foo
  ([x] x)
  ([x y] x)
  ([x y & more]
    x))

(declare foo)

(foo 1 2 3 4 5)

The effect is that the compiler will no longer emit the optimized invoke for foo

So instead of the desired

test.declare_after_def.foo.cljs$core$IFn$_invoke$arity$variadic((1),(2),cljs.core.array_seq([(3),(4),(5)], 0));

we end up with

(test.declare_after_def.foo.cljs$core$IFn$_invoke$arity$5 ? test.declare_after_def.foo.cljs$core$IFn$_invoke$arity$5((1),(2),(3),(4),(5)) : test.declare_after_def.foo.call(null,(1),(2),(3),(4),(5)));

Note that this always takes the "slow" path via .call since test.declare_after_def.foo.cljs$core$IFn$_invoke$arity$5 does not exist.



 Comments   
Comment by Thomas Heller [ 30/Mar/17 4:56 PM ]

The patch re-uses the already defined :redef-in-file warning type which I think is close enough, however in the spirit of better errors a new warning type might be better?

Comment by David Nolen [ 12/May/17 3:55 PM ]

This triggers a bunch of warnings not covered in the patch when running tests. Have you seen this?

Comment by Thomas Heller [ 13/May/17 3:49 AM ]

I changed the ticket a bit since the declare after def seems to be ok in Clojure and doesn't produce a warning there.

The goal is now to just prevent the declare from replacing the analyzer data of a def.

Currently investigating some strange analyzer behaviour that analyzes things twice.

[:redef-meta true]
[:a {:file /Users/zilence/code/oss/clojurescript/src/main/cljs/cljs/core.cljs, :line 945, :column 16, :end-line 945, :end-column 25, :tag boolean, :arglists (quote ([c x])), :doc Evaluates x and tests if it is an instance of the type
  c. Returns true or false}]
[:b {:file cljs/core.cljs, :line 945, :column 16, :end-line 945, :end-column 25, :tag boolean, :arglists (quote ([c x])), :doc Evaluates x and tests if it is an instance of the type
  c. Returns true or false}]

Only :file changes the metadata otherwise remains the same. This triggers a :redef-in-file warning.

Comment by Thomas Heller [ 13/May/17 4:14 AM ]

The new patch prevents a declare from replacing the analyzer data in the compiler env.

The question remains why certain things are analyzed twice but the :redef-in-file warning was fixed by moving the *file-defs* swap.





[CLJS-1991] ClojureScript compiler generates invalid JavaScript code when name contains emoji Created: 30/Mar/17  Updated: 31/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Thai Pangsakulyanont Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: compiler
Environment:

ClojureScript Compiler 1.9.495 (note: I selected 1.9.293 because 1.9.495, the currently released version, is not available)


Attachments: Text File CLJS-1991-Munge-non-identifier-unicode-characters.patch    

 Description   

Clojure (for JVM) handles code that contains emoji just fine, as shown in this example REPL session:

user=> (let [🖌 1] 🖌)
1

However, in ClojureScript, it generates an invalid JavaScript code:

app:cljs.user=> (let [🖌 1] 🖌)
#object[SyntaxError SyntaxError: Invalid or unexpected token]

This is because 🖌 is not a valid JavaScript name.

If this name should not be acceptable in ClojureScript as well, I think the compiler should raise an error during compilation instead of producing an invalid JavaScript code. However, it would be better such names are supported, because 1) Clojure works with such name and 2) it would allow writing code more expressively.

Actual result: Invalid JavaScript code is generated:

var 🖌_38518 = (1);

Expected result: Invalid JavaScript identifiers that's allowed in Clojure should be escaped:

var _1F58C__38518 = (1);


 Comments   
Comment by Thai Pangsakulyanont [ 31/Mar/17 8:24 AM ]

I added a simple patch that fixes this problem. Also a test is added to verify the fix. I have already signed the Clojure CA.


To give an example of how emojis might be useful in ClojureScript, I am creating a web page using ClojureScript and I want to define a color scheme. I could use the “artist palette” emoji to refer to the color palette.

(def 🎨 {:red    "#A4303F"
         :yellow "#FFECCC"
         :green  "#C8D6AF"
         :blue   "#254E70"})

This allows the code to be used like this:

[:div {:style {:color (🎨 :red)}} "Error!"]

One could also take advantage of the colors to make the code easier to understand:

(def ❤️ "#A4303F")
(def 💛 "#FFECCC")
(def 💚 "#C8D6AF")
(def 💙 "#254E70")

Current workaround: It is possible to use an emoji when referring to other namespaces, like this:

(ns mysite.core
  (:require [mysite.theme.colors :as 🎨]))

In this case, 🎨 can be used without generating a syntax error, because after compilation they will be replaced by mysite.theme.colors





[CLJS-1990] Clojurescript programs targeting nodejs should support global installation Created: 28/Mar/17  Updated: 24/Apr/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Greg Haskins Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-CLJS-1990-Use-module-relative-__dirname-for-bootstra.patch    

 Description   

The top-level entry point in a :target :nodejs application uses $CWD relative paths to load the bootstrapping. See "path.resolve('.')" here: https://github.com/clojure/clojurescript/blob/296d0a69340e832b92ed742b3cd0304a06bea27f/src/main/clojure/cljs/closure.clj#L1460 for example.

This works fine for a local build, but is problematic when we try to globally install clojurescript (such as via 'npm install -g') because it requires the caller $CWD to be something that is likely to be unnatural (e.g. /usr/lib/node_modules/$pkg). Suggested fix is to replace "path.resolve('.')" with "__dirname".



 Comments   
Comment by Matt Lee [ 24/Apr/17 2:34 AM ]

Also see: CLJS-1444





[CLJS-1989] s/fdef expansion side effect fails when load cached source Created: 28/Mar/17  Updated: 28/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

s/fdef has an expansion-time side effect that causes it to not operate properly if cached code is loaded.

To repro, have src/foo/core.cljs:

(ns foo.core
 (:require [clojure.spec :as s]))

(defn bar [x])

(s/fdef bar :args (s/cat :x number?))

Then:

$ java -cp cljs.jar:src clojure.main -m cljs.repl.nashorn
To quit, type: :cljs/quit
cljs.user=> (require '[clojure.spec.test :as st] 'foo.core)
true
cljs.user=> (st/instrument)
[foo.core/bar]
cljs.user=> :cljs/quit

Now this has been cached. If you exit and try again, (st/instrument) fails:

$ java -cp cljs.jar:src clojure.main -m cljs.repl.nashorn
To quit, type: :cljs/quit
cljs.user=> (require '[clojure.spec.test :as st] 'foo.core)
true
cljs.user=> (st/instrument)
[]


 Comments   
Comment by Thomas Heller [ 28/Mar/17 11:34 AM ]

s/def is also affected. It uses the cljs.spec/registry-ref atom which has a CLJ side (in cljs/spec.cljc) as well as a CLJS side (in cljs/spec.cljs). The CLJ is not populated when using the cache.





[CLJS-1988] add :npm-deps to recognized compiler options Created: 27/Mar/17  Updated: 27/Mar/17  Resolved: 27/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1988.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 27/Mar/17 2:02 PM ]

fixed https://github.com/clojure/clojurescript/commit/296d0a69340e832b92ed742b3cd0304a06bea27f





[CLJS-1987] don't index node modules blindly Created: 21/Mar/17  Updated: 24/Mar/17  Resolved: 24/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1987.patch    
Patch: Code

 Description   

We shouldn't call `cljs.closure/index-node-modules` if `npm-deps` hasn't been specified



 Comments   
Comment by David Nolen [ 24/Mar/17 12:14 PM ]

fixed https://github.com/clojure/clojurescript/commit/81c37b941fd7336ec620cfff1cfa0d2a5270d23b





[CLJS-1986] Support for ES6 generators Created: 19/Mar/17  Updated: 20/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: James Laver Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File generators.patch    
Patch: Code

 Description   

The attached patch adds support for ES6 generators (supported in node for a while now).

Generator functions can be declared through the :generator metadata that this patch adds support for. There is a new special token, `yield`.



 Comments   
Comment by António Nuno Monteiro [ 19/Mar/17 12:06 PM ]

I don't see how this patch is desirable. The ClojureScript compiler emits ES3 compatible code, which doesn't include generators.

In general, I think it's best to raise issues like this in the mailing list or the Clojurians slack before wasting time doing work that's not going to be accpeted.

Comment by James Laver [ 19/Mar/17 12:25 PM ]

Why is it that we emit ES3 compatible code in particular (I wasn't aware)? Google closure compiler has had support for compiling generators to ES3 for some time now https://github.com/google/closure-compiler/wiki/ECMAScript6

Comment by David Nolen [ 20/Mar/17 2:38 PM ]

I agree that this issues like this need some discussion first. Feel free to start one on the mailing list / Slack or IRC.





[CLJS-1985] `index-node-modules` should pass opts to `node-inputs` Created: 18/Mar/17  Updated: 24/Mar/17  Resolved: 24/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1985.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 24/Mar/17 12:15 PM ]

fixed https://github.com/clojure/clojurescript/commit/8f5d9827553006b3a7b633e8a11c93e12411ef0c





[CLJS-1984] Fix one-argument arity implementation of cljs.closure/index-node-modules Created: 18/Mar/17  Updated: 24/Mar/17  Resolved: 24/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: Next
Fix Version/s: Next

Type: Defect Priority: Trivial
Reporter: Thomas Spellman Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bug, patch
Environment:

N/A


Attachments: Text File CLJS-1984.patch    
Patch: Code

 Description   

cljs.closure/index-node-modules is a multimethod, and the 1-arity args are getting dropped in the pass to the 2-arity method causing it to loop until stack overflow. The attached patch fixes it in latest master (1.9.508).



 Comments   
Comment by David Nolen [ 24/Mar/17 12:20 PM ]

fixed https://github.com/clojure/clojurescript/commit/52ff7a2bdcaacf840f7aae72f4be4575297f7db1





[CLJS-1983] res -> mres in spec.cljs Created: 17/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1983.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 17/Mar/17 2:26 PM ]

fixed https://github.com/clojure/clojurescript/commit/c2fbded498033515cbe32db122b2860a1245f4e1





[CLJS-1982] Backtick of a quoted namespace should not change it Created: 16/Mar/17  Updated: 14/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Andrea Richiardi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Little inconsistence with Clojure here:

boot.user=> `'my-namespace.test-runner
(quote my-namespace.test-runner)

while in lumo, planck and replumb (notice the slash instead of the dot):

cljs.user=> `(require 'my-namespace.test-runner)
(cljs.core/require (quote my-namespace/test-runner))

this happens in a normal repl as well. Some other examples:

cljs.user=> `'my-namespace.test-runner
(quote my-namespace/test-runner)
cljs.user=> `'my-namespace.test-runner.ars
(quote my-namespace/test-runner.ars) ;; second not changed





[CLJS-1981] ./script/bootstrap fails on FreeBSD 11.0 Created: 15/Mar/17  Updated: 07/Apr/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: Next
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Duncan Bayne Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bootstrap, bug
Environment:

$ git rev-list HEAD | head -n 1
f7d08ba3f837f3e2d20ebdaf487221b18bb640c7

$ uname -a
FreeBSD x220 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64

$ java -version
openjdk version "1.8.0_112"
OpenJDK Runtime Environment (build 1.8.0_112-b16)
OpenJDK 64-Bit Server VM (build 25.112-b16, mixed mode)



 Description   

When I run ./script/bootstrap, it fails when trying to invoke unzip. I think it's expecting GNU/Linux unzip, or something similar:

$ ./script/bootstrap
Usage: unzip [-aCcfjLlnopqtuvyZ1] [-d dir] [-x pattern] zipfile
The 'unzip' utility is missing, or not on your system path.



 Comments   
Comment by David Nolen [ 17/Mar/17 1:51 PM ]

I'm assuming you can install unzip no? If not then please provide a patch that generalize the bootstrap script. Thanks.

Comment by Duncan Bayne [ 06/Apr/17 2:08 AM ]

Yes, unzip is already installed. I'll attempt to generalize it.

If that fails - that is, if there is no suitable set of common arguments to GNU unzip and BSD unzip - I'll detect the unzip type and send the correct commands.

Comment by David Nolen [ 07/Apr/17 11:08 AM ]

This just doesn't seem like a problem. Just install unzip, just like you need to install Java etc.





[CLJS-1980] port CLJ-2100 (s/nilable form should retain original spec form) Created: 14/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: spec

Attachments: Text File CLJS-1980.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 17/Mar/17 1:47 PM ]

fixed https://github.com/clojure/clojurescript/commit/1c9802043de28b8c331bc7e3c27b651450147731





[CLJS-1979] Port CLJ-2043 (fix s/form of s/conformer) Created: 14/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: spec

Attachments: Text File CLJS-1979.patch    
Patch: Code

 Description   

this is in clojure 1.9.0-alpha15



 Comments   
Comment by David Nolen [ 17/Mar/17 1:50 PM ]

fixed https://github.com/clojure/clojurescript/commit/6f4b313e4f9523e9e8345f13c4a55bb1b6f93ebc





[CLJS-1978] Port CLJ-2035 Created: 14/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: spec

Attachments: Text File CLJS-1978.patch    
Patch: Code and Test

 Description   

CLJ-2035 has made it into Clojure 1.9.0-alpha15



 Comments   
Comment by António Nuno Monteiro [ 14/Mar/17 12:40 PM ]

Attached patch with fix and tests.

Comment by David Nolen [ 17/Mar/17 1:54 PM ]

fixed https://github.com/clojure/clojurescript/commit/e6abaa746e815f9f040484f0647b2173bfc45592





[CLJS-1977] defrecord should use murmur hashing like Clojure Created: 13/Mar/17  Updated: 17/Mar/17

Status: Reopened
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Francis Avila Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Due probably to an oversight, defrecord uses the older hash-imap method of hashing instead of the newer murmur hashing used by Clojure. Clojure does the equivalent of this:

(bit-xor (hash "full.class.name.of.Record") (hash-unordered-coll the-record))

This would also allow us to remove the internal functions hash-iset (which is already unused) and hash-imap (which is only used by records).






[CLJS-1976] hash-map assoc stackoverflow Created: 13/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Francis Avila Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

Using clojurescript master and a browser environment


Attachments: Text File CLJS-1976.patch    

 Description   

A particular combination of keys in a hash-map will cause a stackoverflow when added into the same hash-map, whether using transient or non-transient assoc.

Minimal case:

(defrecord T [index a b])

(def bad-key-1 (map->T {:index :eavt, :a 17592186192276, :b nil}))
(def bad-key-2 (map->T {:index :avet, :a 10, :b :fhir.ElementDefinition/minValueDateTime$cr}))

;; Implicit Transient assoc
(hash-map bad-key-1 nil bad-key-2 nil)

;RangeError: Maximum call stack size exceeded

;;; From a browser console:
;core.cljs:5034 Uncaught RangeError: Maximum call stack size exceeded
;cljs.core.PersistentVector.cljs$core$ISeqable$_seq$arity$1 @ core.cljs:5034
;cljs$core$seq @ core.cljs:1121
;cljs.core.concat.cljs$core$IFn$_invoke$arity$2 @ core.cljs:3619
;cljs.core.LazySeq.sval @ core.cljs:3269
;cljs.core.LazySeq.cljs$core$ISeqable$_seq$arity$1 @ core.cljs:3323
;cljs$core$seq @ core.cljs:1121
;cljs.core.pr_str.call.cljs.user.T.cljs$core$ISeqable$_seq$arity$1 @ VM2295:158
;cljs$core$seq @ core.cljs:1121
;cljs$core$first @ core.cljs:1143
;(anonymous) @ core.cljs:4049
;cljs$core$every_QMARK_ @ core.cljs:4049
;cljs$core$equiv_map @ core.cljs:5836
;(anonymous) @ VM2295:114
;cljs.core.pr_str.call.cljs.user.T.cljs$core$IEquiv$_equiv$arity$2 @ VM2295:118
;cljs$core$_equiv @ core.cljs:617
;cljs.core._EQ_.cljs$core$IFn$_invoke$arity$2 @ core.cljs:1179
;cljs$core$key_test @ core.cljs:6494
;cljs.core.BitmapIndexedNode.inode_assoc_BANG_ @ core.cljs:6752
;cljs.core.create_node.cljs$core$IFn$_invoke$arity$7 @ core.cljs:7050
;(anonymous) @ core.cljs:6760
;;; Last 3 lines repeat forever


;; Explicit non-transient assoc
(assoc (hash-map bad-key-1 nil) bad-key-2 nil)

;RangeError: Maximum call stack size exceeded
;;; Stack is similar to above, except `inode-assoc` instead of `inode-assoc!`
;;; is repeating, because this version is not transient

As near as I can tell, the fundamental problem is that the (zero? (bit-and bitmap bit)) test in inode-assoc is always false. I have a hunch this is due to some bit-twiddling difference between js and Java that isn't accounted for in bit-count or bitmap-indexed-node-index or the recursive call to inode-assoc. I am investigating further.



 Comments   
Comment by Francis Avila [ 13/Mar/17 6:13 PM ]

(Just to note: we encountered this issue in production.)

The fundamental problem is that JS hash values may use more than 32 bits, but only 32 bits should be considered.

These two records have different hash values, but if only 32 bits are compared they have the same hash value. At least create-node naively assumes that hash values are normalized and does normal comparison between them using ==, meaning it does not detect the hash collision correctly.

This is a problem for records because they use an older (pre-murmur) hash-imap, which is not careful to truncate to 32 bits.

However, it is also a problem for dates for the same reason:

(hash-map #inst "2017-03-13T22:21:08.666-00:00" nil  #inst "2015-11-02T19:53:15.706-00:00" nil)
;RangeError: Maximum call stack size exceeded

My proposed fix is to force all hash values to be normalized to 32 bits to preserve the invariant that two equal hash values means they collide.

Comment by David Nolen [ 17/Mar/17 2:24 PM ]

fixed https://github.com/clojure/clojurescript/commit/3449c5328356fb4951d1a950158b88e339818d0b





[CLJS-1975] Perf: Compare f with nil in Delay impl Created: 11/Mar/17  Updated: 11/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: performance

Attachments: Text File CLJS-1975.patch    
Patch: Code

 Description   

When a Delay has been realized, f is set to nil. We can avoid truth_ and not calls and directly compare with nil for a minor perf boost.

In script/noderepljs, this leads to these

(simple-benchmark [x (delay 1)] @x 1e9)
(simple-benchmark [x (delay 1)] (realized? x) 1e9)
(simple-benchmark [x (doto (delay 1) deref)] (realized? x) 1e9)

speeding up by 6%, 11% and 9%, respectively.






[CLJS-1974] Remove cljs.core/fixture1 and fixture2 Created: 11/Mar/17  Updated: 11/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-1974.patch    
Patch: Code

 Description   

There are a couple of vars in cljs.core named fixture1 and fixture2 that appear to perhaps be leftovers from when tests were assertions included in the cljs.core namespace.

https://github.com/clojure/clojurescript/commit/43861f7bc0b7b4fb534167b0773e49ccb68e6b1e#diff-a98a037c6c098dd3707e861df3c2f5acR1893

These can probably be safely removed.






[CLJS-1973] Add support for `:npm-deps` in upstream `deps.cljs` Created: 11/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Enhancement Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1973.patch    
Patch: Code

 Comments   
Comment by Thomas Heller [ 12/Mar/17 4:19 AM ]

Wrote about this in Slack but I wanted to properly voice my concerns so they don't get lost in Slack archives.

I think managing npm via CLJS is a bad idea. While this is very interesting it could/should probably happen in a library. We will inherit all the woes npm brings and force this onto the user. What if the user prefers yarn? What if the user is using a tool with support for package.json but not deps.cljs?

I voiced similar concerns a while ago [1] and with everything happening recently with regards to JS modules the situation is getting worse. It may appear that this work must happen in CLJS but really could happen somewhere else without making cljs.core more complicated. clojure.core doesn't bundle with leiningen for good reason.

IMHO, YMMV

[1] https://groups.google.com/d/msg/clojurescript/xMQuEmQt7oQ/AWT5RZe_nQQJ

Comment by David Nolen [ 17/Mar/17 2:23 PM ]

fixed https://github.com/clojure/clojurescript/commit/21da03e03e229a0b38fb872485d26a30fbf034b8





[CLJS-1972] cljs.nodejs/enable-util-print! identical to enable-console-print Created: 10/Mar/17  Updated: 10/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

cljs.nodejs/enable-util-print! is identical to the cljs.core/enable-console-print! and should probably rather re-use than having duplicate code.






[CLJS-1971] Typos in docstring of require macro Created: 08/Mar/17  Updated: 08/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Shogo Ohta Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: docstring

Attachments: Text File CLJS-1971.patch    
Patch: Code

 Description   

The example code in the docstring looks not right:

cljs.user=> (doc require)
-------------------------
cljs.core/require
([& args])

...

Example:

  The following would load the library clojure.string :as string.

  (require '[clojure/string :as string])
nil
cljs.user=>





[CLJS-1970] Cannot infer target type for list/vector expressions Created: 08/Mar/17  Updated: 10/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Daniel Janus Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 16.04.2, Oracle JRE 8



 Description   

With

(set! *warn-on-infer* true)
enabled, attempting to compile functions like:

(defn foo [] (list))
(defn bar [] (vector))

results in a warning:

WARNING: Cannot infer target type in expression (. cljs.core/List -EMPTY) at line 2427 src/cljs/discann/core.cljs

WARNING: Cannot infer target type in expression (. cljs.core/PersistentVector -EMPTY) at line 2435 src/cljs/discann/core.cljs

The line number reported is totally unrelated to the line of code where the problematic fn appears.

Affects 1.9.456 and 1.9.494.






[CLJS-1969] Docstring for condp indicates IllegalArgumentException Created: 07/Mar/17  Updated: 07/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: docstring

Attachments: Text File CLJS-1969.patch    
Patch: Code

 Description   

The docstring for condp indicates IllegalArgumentException is thrown. Instead it should indicate Error (as does case's docstring, for example.)






[CLJS-1968] Enable calling JS modules that export a single function Created: 07/Mar/17  Updated: 10/Mar/17  Resolved: 10/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Enhancement Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1968.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 10/Mar/17 12:53 PM ]

fixed https://github.com/clojure/clojurescript/commit/1d38f73a86081ad54cb230c507fbae183d768d6b





[CLJS-1967] Missing ^boolean annotation for removed-leaf? in TransientHashMap Created: 07/Mar/17  Updated: 10/Mar/17  Resolved: 10/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1967.patch    
Patch: Code

 Description   

The `removed-leaf?` is a boxed boolean and can be annotated.



 Comments   
Comment by Thomas Mulvaney [ 07/Mar/17 9:18 AM ]

Attached patch uses the provided `val` field of the `Box` type rather than setting a new field.

Comment by David Nolen [ 10/Mar/17 1:20 PM ]

fixed https://github.com/clojure/clojurescript/commit/62337d018bf9902fe8943289b9d7f3bf5c698bff





[CLJS-1966] cljs.test assumes the output directory is '/out/' when determining the filename for a failed or errored test result. Created: 06/Mar/17  Updated: 06/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Creighton Kirkendall Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If your output directory is does not contain '/out/' in the path the code for getting the filename on failure for test results will return nonsense.

You can see here where we we make the assumption that '/out/' is used.
https://github.com/clojure/clojurescript/blob/2f8a1529955acc943ac8082ab5848b2cba54bc4d/src/main/cljs/cljs/test.cljs#L379






[CLJS-1965] letfn collisions across namespaces Created: 02/Mar/17  Updated: 02/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Jeremy R Sellars Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Affects 1.9.495 and earlier. Probably only affects browsers (not nodejs).


Attachments: Text File cljs-1965_wrap_letfn_statements.patch    

 Description   

If you `letfn` a fn with the same name in two namespaces, the wrong fn is used.

one.cljs
(ns hello-world.one)

(letfn [(answer [] "1")]
  (defn get-answer []
    (answer)))
two.cljs
(ns hello-world.two)

(letfn [(answer [] "2")]
  (defn get-answer []
    (answer)))
core.cljs
(ns hello-world.core
  (:require [hello-world.one]
            [hello-world.two]))

(println "one =>" (hello-world.one/get-answer))  ; one => 1
(println "two =>" (hello-world.two/get-answer))  ; two => 1      WHAT?!?

This issue seems to exist both on top-level `letfn`s and non-top-level `(let [] (letfn [...]))`.



 Comments   
Comment by Jeremy R Sellars [ 02/Mar/17 4:21 PM ]

This patch wraps `letfn` :expr and :statement forms in a function declaration (formerly, only :expr forms were wrapped).

I only did minimal testing. It fixes the code from the description.

Note: This is my first crack at the compiler and it is entirely possible I have not understood the entire problem.





[CLJS-1964] Validate that `:target :nodejs` and no optimizations requires a `:main` option to be present Created: 01/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: newbie, nodejs

Attachments: Text File CLJS-1964.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 17/Mar/17 2:44 PM ]

fixed https://github.com/clojure/clojurescript/commit/197ff2e7c3f96b365e31cf4c1a4af39bdd60fc88





[CLJS-1963] cljs.analyzer/load-core is called for every analyzed form Created: 01/Mar/17  Updated: 01/Mar/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In cljs.analyzer/analyze-form the load-core fn is called. load-core guards against doing its work multiple times. It then always calls (intern-macros 'cljs.core), which also checks whether it was called before. This ends up doing the checks very often. load-core should probably be called in a less frequent manner.

Performance impact is very minimal but I did a quick test in my work project and load-core is called 416671 times there (without cache) when 1 would be enough.






[CLJS-1962] Quick start guide unnecessarily uses rlwrap to run commands Created: 28/Feb/17  Updated: 28/Feb/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.76
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Jeff Younker Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: documentation
Environment:

Quick start guild



 Description   

At least one example command in the quick start guide uses rlwrap. The command rlwrap is unnecessary to run the command, and it is not installed on all systems (e.g. windows or OSX). This creates an unnecessary stumbling block on these systems, so rlwrap should be removed from the examples in the guide.






[CLJS-1961] Regression in :advanced output Created: 28/Feb/17  Updated: 28/Feb/17  Resolved: 28/Feb/17

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

I wanted to upgrade my work project to any release after 1.9.293, but it started showing weird errors when running the compiled JS in the browser.

I ran git bisect and identified the bad commit [1].

git bisect bad
de05b15568c848a1d4f80a44bdffd486abd05150 is the first bad commit
commit de05b15568c848a1d4f80a44bdffd486abd05150
Author: António Nuno Monteiro <anmonteiro@gmail.com>
Date:   Mon Nov 7 12:07:32 2016 +0100

    CLJS-1768: cljs.spec perf tweaks

    This patch implements the changes in the following commits:

    https://github.com/clojure/clojure/commit/de6a2b528a18bcb4768e82d0d707d2cab26268a6
    https://github.com/clojure/clojure/commit/defa7b8ef268ea2b8772658ade2010ca5ad00dc4
    https://github.com/clojure/clojure/commit/021a3adf131d3f4158acd9e5d08ca91eb36ab56d
    https://github.com/clojure/clojure/commit/9fa85c6a908c9a3e89b4c0c449c49887a4c35248

:040000 040000 f8eee4c6e8289c5ec539c478e67c48d0de485f84 f261f856c8492bd4880be536186ccc8ad3fe3557 M    src

The error is very confusing as it happens at a point in the code where spec isn't even involved. When running the :advanced build with :pseudo-names the bug disappears as well making this very hard to track down. I think I have ruled out all other factors and the only thing that changes is this commit. Must be something that confuses the Closure Compiler.

This works: git reset --hard de05b15568c848a1d4f80a44bdffd486abd05150~1
This does not: git reset --hard de05b15568c848a1d4f80a44bdffd486abd05150

https://github.com/clojure/clojurescript/commit/de05b15568c848a1d4f80a44bdffd486abd05150



 Comments   
Comment by Thomas Heller [ 28/Feb/17 5:08 AM ]

Well, externs should have been my first guess.

In this case I accidentally removed externs for Google Analytics which is just one global var "ga". Which replaced whatever the Closure compiler generated for that leading me down a completely wrong path trying to track this down.

Sorry for the noise (again).





[CLJS-1960] Require CommonJS modules directly from a ClojureScript namespace Created: 27/Feb/17  Updated: 10/Mar/17  Resolved: 10/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Enhancement Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 3
Labels: None

Attachments: Text File CLJS-1960.patch    
Patch: Code

 Comments   
Comment by Andrea Richiardi [ 27/Feb/17 11:34 PM ]

I will comment again after I'll try the patch, but this is very good stuff. One thing I was pondering about is the name of the option. It could be more generic, for instance :js-deps, so that we kind of abstract from the package manager. I know I know everybody knows what npm is...Anyways, my two cents.

Comment by Andrea Richiardi [ 01/Mar/17 5:09 PM ]

Ok I tried the new patch and I detected that it basically throws (sorry it is a bit verbose):

Error: Cannot find module '/home/arichiardi/git/rest-resources-viz/home/arichiardi/.boot/cache/tmp/glu/-d8mh6z/main.out/cljs$node_modules.js' from '/home/arichiardi/git/rest-resources-viz'

But it looks like the file is there, and if I escape the $ with a \$, the file can be read

Comment by David Nolen [ 10/Mar/17 1:09 PM ]

fixed https://github.com/clojure/clojurescript/commit/777d41b9b6fe83c3d29fc51ee3ddbdfeff4f803b





[CLJS-1959] under :nodejs target we should provide __dirname and __filename constants Created: 27/Feb/17  Updated: 27/Feb/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None





[CLJS-1958] Macro :arglists include &form and &env Created: 27/Feb/17  Updated: 27/Feb/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Andrea Richiardi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Minor issue, but nice to fix especially because of tooling. In lumo:

cljs.user=> (:arglists (get-in @lumo.repl/st [:cljs.analyzer/namespaces 'cljs.core$macros :defs 'when]))
([&form &env test & body])

I would like to filter out the first two arguments that are of course not needed.
A simple patch is here.

I can provide a patch once I figure out where is the right place to apply it. Of course if I am not doing it wrong.

Thanks!



 Comments   
Comment by Andrea Richiardi [ 27/Feb/17 12:26 PM ]

On second thought, if we put this filter in `load-analysis-cache!`, probably we will pay to much of a price for just a display/ide problem. The best thing I can think of is to filter the transit/json file before loading. So probably this is better to be inside `lumo`.

Comment by Andrea Richiardi [ 27/Feb/17 12:44 PM ]

After conversation with António Nuno Monteiro: this inconsistency might be solved with CLJS-1461 so this one here can be closed I guess.





[CLJS-1957] Process JS modules errors and warnings don't get printed Created: 27/Feb/17  Updated: 10/Mar/17  Resolved: 10/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1957.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 10/Mar/17 1:36 PM ]

fixed https://github.com/clojure/clojurescript/commit/f7d08ba3f837f3e2d20ebdaf487221b18bb640c7





[CLJS-1956] Add missing JS reserved keywords Created: 27/Feb/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1956.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 17/Mar/17 2:33 PM ]

fixed https://github.com/clojure/clojurescript/commit/2171ae9859a2e982497764a04de10916aae68307





[CLJS-1955] data_readers.cljc can't reference handlers in user code Created: 27/Feb/17  Updated: 27/Feb/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Dustin Getz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: compiler
Environment:

clojurescript 1.9.456-493



 Description   

data_readers.cljc:

{a/UserIdentity foo.core/user-identity}
(ns foo.core)
(defn user-identity [i] i)
(assert (= 1 #a/UserIdentity 1))

`CompilerException java.lang.IllegalStateException: Attempting to call unbound fn: #'foo.core/user-identity

Using a #' in data_readers.cljc results in a different error:
`java.lang.ClassCastException: clojure.lang.Cons cannot be cast to clojure.lang.Named`






[CLJS-1954] "async" needs special munging since Feb2017 closure compiler Created: 25/Feb/17  Updated: 13/Apr/17  Resolved: 13/Apr/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Blocker
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Completed Votes: 8
Labels: None

Patch: Code and Test

 Description   

I tried to release a new chromex library version and hit strange errors generated by new Closure compiler:

Feb 25, 2017 9:16:59 PM com.google.javascript.jscomp.LoggerErrorManager println
    SEVERE: /Users/darwin/code/chromex/test/.compiled/optimizations_advanced/cljs/core/async.js:1418: ERROR - Parse error. No newline allowed before '=>'
    var inst_18944 = async(inst_18943);
                                      ^
    
    Feb 25, 2017 9:16:59 PM com.google.javascript.jscomp.LoggerErrorManager printSummary

The problem is that "async" is kind of a reserved word in new Closure compiler. And code like this[1] will newly break advanced compilation.

I tried to fix it by adding "async" into list of js-reserved keywords in ClojureScript compiler, but this introduced another issue. Namespaces are subject of munging, so usage of goog.async.* stuff will break[2]. Also the compiler emitted a bunch of warnings about using reserved keywords in namespace names. I saw no easy way how to distinguish those cases. At least I created a dirty solution by hard-coding some extra logic into `munge` implementation just to fix my use-case. But in general this will probably require more precise solution.

[1] https://github.com/clojure/core.async/blob/d17eb8a50cfb022b83c0ba53715451a8fe2fd5fa/src/main/clojure/cljs/core/async.cljs#L270
[2] https://github.com/clojure/core.async/blob/d17eb8a50cfb022b83c0ba53715451a8fe2fd5fa/src/main/clojure/cljs/core/async/impl/dispatch.cljs#L29



 Comments   
Comment by Antonin Hildebrand [ 25/Feb/17 4:28 PM ]

I marked this as a blocker because core.async is heavily used and it newly breaks due to this issue in advanced mode.

You might want to grab the test and patches from here:
https://github.com/clojure/clojurescript/compare/master...darwin:cljs-1954

Although that fixed the immediate problems in my scenario, I assume you want to handle namespace munging in a more robust way. In rare cases there might be user-specified closure modules with "async" in their names as well, not only goog.async.

Comment by Antonin Hildebrand [ 25/Feb/17 4:41 PM ]

This is a dupe of CLJS-1953. Sorry, didn't see that.

Comment by Brandon Bloom [ 01/Mar/17 9:23 PM ]

This seems like a Google Closure Compiler bug: It shouldn't choke on "async" unless it precedes "function" or an arrow lambda (=>), since async isn't a reserved word (as far as I can tell), only a contextual keyword. Might get a quick response/fix if you file an issue over at https://github.com/google/closure-compiler

CLJS can probably workaround this, and arguably should, since if not invalid, using "async" as an identifier" is at least confusing with traditional syntax highlighting tools, etc.

Comment by António Nuno Monteiro [ 01/Mar/17 9:26 PM ]

This has been reported and a fix is in progress. Here's the ticket: https://github.com/google/closure-compiler/issues/2336

Comment by Len Weincier [ 27/Mar/17 2:35 AM ]

I see the closure-compiler issue is closed. Whats the process for this to hit Clojurescript ?

Comment by Dieter Komendera [ 27/Mar/17 3:46 AM ]

@Len as far as I know we first have to wait for a new release of the Closure compiler until we can bump it as done in http://dev.clojure.org/jira/browse/CLJS-1952

Comment by David Nolen [ 13/Apr/17 2:26 PM ]

fixed by http://dev.clojure.org/jira/browse/CLJS-2006





[CLJS-1953] JSC_PARSE_ERROR during prod compilation after update clojurescript to version 1.9.494 from 1.9.229. Created: 25/Feb/17  Updated: 10/Mar/17  Resolved: 10/Mar/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Critical
Reporter: Pavel Kopychenko Assignee: Unassigned
Resolution: Duplicate Votes: 2
Labels: bug, compiler
Environment:

GNU/Linux Debian 8 x64, java version "1.8.0_121", , clojure 1.8, clojurescript 1.9.494, Leiningen 2.7.1, lein-cljsbuild "1.1.5", core.async "0.3.441"



 Description   

I have a next error when I try to compile my project as prod after update clojurescript to last release version 1.9.494 from 1.9.229 :

Compiling "resources/public/js/c/camerton/testor/main.js" from ["src-cljc" "src-cljs-common" "src-cljs-testor"]...
Feb 25, 2017 3:40:05 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /home/maker/git/camerton/target/cljsbuild-compiler-3/cljs/core/async.js:1426: ERROR - Parse error. No newline allowed before '=>'
var inst_56769 = async(inst_56768);
                                  ^

Feb 25, 2017 3:40:05 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. No newline allowed before '=>' at /home/maker/git/camerton/target/cljsbuild-compiler-3/cljs/core/async.js line 1426 : 34


 Comments   
Comment by Antonin Hildebrand [ 25/Feb/17 4:39 PM ]

Ah, sorry. I searched for "async" in existing JIRA tickets and didn't get this one. So I created a new one here CLJS-1954.





[CLJS-1952] Bump Closure Compiler to Feb 2017 release Created: 23/Feb/17  Updated: 24/Feb/17  Resolved: 24/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Enhancement Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1952.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 24/Feb/17 12:42 PM ]

fixed https://github.com/clojure/clojurescript/commit/be768300d88bef57ac6db05e7d4d26878ea2c634





[CLJS-1951] Missing 0 and 1 arity versions of interleave Created: 23/Feb/17  Updated: 24/Feb/17  Resolved: 24/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1951.patch    
Patch: Code and Test

 Description   

For compatibility with Clojure, `interleave` should have 0 and 1 arity versions.



 Comments   
Comment by David Nolen [ 24/Feb/17 12:45 PM ]

fixed https://github.com/clojure/clojurescript/commit/fa7c692f4e01941ac83be04534b1603828cd134b





[CLJS-1950] Eliminate instances of #^ Created: 21/Feb/17  Updated: 22/Feb/17  Resolved: 22/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1950.patch    
Patch: Code

 Description   

With CLJS-1636 I had, without thinking, blindly followed the existing pattern used to mark def s as private, employing

#^:private

This ticket is to remove those new and the existing instance of this older syntax.



 Comments   
Comment by David Nolen [ 22/Feb/17 6:52 AM ]

fixed https://github.com/clojure/clojurescript/commit/6325a29612b6266ee786ce49a83f12566708e696





[CLJS-1949] Self-host: cljs.compiler/munge doesn't preserve JVM compiler semantics Created: 21/Feb/17  Updated: 22/Feb/17  Resolved: 22/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1949.patch    
Patch: Code and Test

 Comments   
Comment by António Nuno Monteiro [ 21/Feb/17 5:17 PM ]

Attached patch with fix and test.

Comment by Mike Fikes [ 21/Feb/17 5:30 PM ]

FWIW, I tried the attached patch downstream with Planck and it worked. Prior to the patch, I observed this behavior:

cljs.user=> (.catch (js/Promise. #(%2 "x")) #(println %))
(new Promise((function (p1__20_SHARP_,p2__19_SHARP_){
return p2__19_SHARP_.call(null,"x");
}))).catch$ is not a function. (In '(new Promise((function (p1__20_SHARP_,p2__19_SHARP_){
return p2__19_SHARP_.call(null,"x");
}))).catch$((function (p1__21_SHARP_){
return cljs.core.println.call(null,p1__21_SHARP_);
}))', '(new Promise((function (p1__20_SHARP_,p2__19_SHARP_){
return p2__19_SHARP_.call(null,"x");
}))).catch$' is undefined)

And with the patch:

cljs.user=> (.catch (js/Promise. #(%2 "x")) #(println %))
x
#object[Promise [object Promise]]
Comment by David Nolen [ 22/Feb/17 6:56 AM ]

fixed https://github.com/clojure/clojurescript/commit/025dd9d3e57f1955fd442b9f69823c892a38cb58





[CLJS-1948] Possible race condition in compiler w/ parallel-build true Created: 21/Feb/17  Updated: 25/Feb/17  Resolved: 24/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Nikita Prokopov Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Zip Archive datascript_compiler_race.zip    

 Description   

I'm seeing errors trying to compile DataScript on 1.9.473. Judging from output, it looks like a race error in ClojureScript compiler: output JS files are damaged, removing parallel-build true fixes the problem.

Due to the nature of error, it might not be 100% reproducible. I get it 100% times on my machine though, but reported syntax errors in JS are always different.

The problem was probably introduced in 1.9.229. I'm not getting any errors compiling DataScript in earlier versions (1.9.227 and before)

HOW TO REPRODUCE:

unzip datascript_compiler_race.zip
cd datascript_compiler_race
wget https://github.com/clojure/clojurescript/releases/download/r1.9.473/cljs.jar
rm -rf target && java -cp cljs.jar:src clojure.main build.clj

As this is a race condition, it might not reproduce perfectly every time.

Examples of what I get on my MacBook Pro Retina Mid 2012 (Core i7-3615QM, 4 cores):

[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: parse-binding at line 215 is being replaced at line 215 src/datascript/parser.cljc
WARNING: collect-vars-acc at line 470 is being replaced at line 470 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
Feb 21, 2017 1:07:13 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:140: ERROR - Parse error. Semi-colon expected
datascript.parser.collect.cljsdatascript.parser.collect.cljs$lang$mavar G__16546 = cljs.datascript.parser.collvar seq16545__$1 = cljs.core.next(seq16545);
                                                                        ^

Feb 21, 2017 1:07:13 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:1676: ERROR - Parse error. IE8 (and below) will parse trailing commas in array and object literals incorrectly. If you are targeting newer versions of JS, set the appropriate language_in option.
return faif(cljs.coredatascript.parser.RuleVars.prototype.cljs$core$IMap$_dissoc$arity$2 = (function (this__7667__auto__,k__7668return ((this__7654__auto____$1.constructor === other__7655__autoif(cljs.core.contains_QMARK_(new cljs.core.PersistentHashSet(null, new cljs.core.PersistentArrayMap(null, 2, [cljs.core.cst$kw$free,return true;
                                                                                                                                                                                                                                                                                                                                    ^

Feb 21, 2017 1:07:13 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 2 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. Semi-colon expected at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 140 : 72
ERROR: JSC_TRAILING_COMMA. Parse error. IE8 (and below) will parse trailing commas in array and object literals incorrectly. If you are targeting newer versions of JS, set the appropriate language_in option. at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 1676 : 324
[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: parse-binding at line 215 is being replaced at line 215 src/datascript/parser.cljc
WARNING: parse-clause at line 598 is being replaced at line 598 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
WARNING: parse-clauses at line 611 is being replaced at line 611 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
Feb 21, 2017 1:05:50 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:458: ERROR - Parse error. Semi-colon expected
datasreturn cljs.core.pr_sequential_writer(writer__7673__auto__,pr_pair__7675__auto__,"#datascript.parser.Variable{",", ","}",opts__7674__auto__,cljs.core.concat.cljs$core$IFn$_invoke$arity$2(new cljs.core.PersistentVector(null, 1, 5return (new cljs.core.RecordIter((0),G__16721__$1,1,new cljs.core.PersistentVector(null, 1, 5, cljs.core.PersistentVector.EMPTY_NODE, [cljs.core.cst$kw$symbol], null),(cljs.core.truth_(self__.__extmap)?cljs.core._iterator(self__.__extmap):cljs.core.nil_iter())));
            ^

Feb 21, 2017 1:05:50 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:4080: ERROR - Parse error. IE8 (and below) will parse trailing commas in array and object literals incorrectly. If you are targeting newer versions of JS, set the appropriate language_in option.
throw cljs.core.ex_info.cljs$core$IFn$_invoke$arity$2([cljs.core.str.cljs$cothrow cljs.core.ex_info.cljs$core$IFn$_invoke$arity$2([cljs.core.str.cljs$core$IFn$_invoke$arity$1("Cannot parse pull expression, expect ['pull' src-var? variable (constant | variable | plain-symbol)]")].join(''),new cljs.core.PersistentArrayMap(null, 2, [cljs.core.cst$kw$error,}
                                                                                                                                                                                                                                                                                                                                                                  ^

Feb 21, 2017 1:05:50 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 2 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. Semi-colon expected at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 458 : 12
ERROR: JSC_TRAILING_COMMA. Parse error. IE8 (and below) will parse trailing commas in array and object literals incorrectly. If you are targeting newer versions of JS, set the appropriate language_in option. at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 4080 : 354
[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: parse-binding at line 215 is being replaced at line 215 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
Feb 21, 2017 1:02:55 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:4507: ERROR - Parse error. ',' expected
throw cljs.core.ex_info.cljs$core$IFn$_invoke$arity$2([cljs.core.str.cljs$core$IFn$_invoke$arity$1("Cannot parse :find, expected: (find-rel | find-coll | find-tuple | find-scalar)")].join(''),new cljs.core.PersistentArrayMap(null, 2, [cljs.core.cst$kw$error,cljs.core.cst$kw$parser_SLASH_find,cljs.core.cst$kw$fragment,forvar or__6983__}
                                                                                                                                                                                                                                                                                                                                      ^

Feb 21, 2017 1:02:55 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. ',' expected at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 4507 : 326
[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: collect-vars-acc at line 470 is being replaced at line 470 src/datascript/parser.cljc
WARNING: parse-clause at line 598 is being replaced at line 598 src/datascript/parser.cljc
WARNING: parse-clauses at line 611 is being replaced at line 611 src/datascript/parser.cljc
Feb 21, 2017 1:02:00 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:227: ERROR - Parse error. ',' expected
this.datascript.parser.Placeholder.prototype.cljs$core$ILookup$_lookup$arity$2 = (function (this__7658_this.cljs$lang$protocol_mask$partition1$ = 81var thidatascript.parser.Placeholdereturn this__7658__auto____$1.cljs$core$ILookup$_lookup$arity$3(null,k__7659__auto__,null);
                                                                                                           ^

Feb 21, 2017 1:02:00 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. ',' expected at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 227 : 107
[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: parse-binding at line 215 is being replaced at line 215 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
Feb 21, 2017 1:00:46 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/out/datascript/parser.js:215: ERROR - Parse error. Character '@' (U+0040) is not a valid identifier start char
datascript.parser.Placeholder = (functio * @implements {cljs.core.IAthis.__meta  * @implemthis.__extmap = __extm * @this.__hash = __hash;
                                           ^

Feb 21, 2017 1:00:46 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. Character '@' (U+0040) is not a valid identifier start char at /Users/prokopov/datascript_compiler_race/out/datascript/parser.js line 215 : 43
[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: collect-vars-acc at line 470 is being replaced at line 470 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
WARNING: parse-clause at line 598 is being replaced at line 598 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
WARNING: parse-clauses at line 611 is being replaced at line 611 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
Feb 21, 2017 12:59:33 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/out/datascript/parser.js:7639: ERROR - Parse error. '}' expected

Feb 21, 2017 12:59:33 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. '}' expected at /Users/prokopov/datascript_compiler_race/out/datascript/parser.js line 7639 : 0

Note how output JS is not even syntactically correct:

functio * @implements
__meta  * @implemthis.__extmap
,forvar or__6983__}

This is a clear sign that two or more threads are writing to the same file without coordination.

Also note that with parallel build enabled, compiler confuses declare with function defenition and warns about collect-vars-acc at line 470 is being replaced at line 470. In fact, the function is first decalre-d, then defn-ed just once in the same file, which, under normal circumstances, should not trigger any warnings.

Also note that setting :parallel-build false leads to 100% stable, error-less builds:

[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj --no-parallel
[~/datascript_compiler_race]


 Comments   
Comment by David Nolen [ 22/Feb/17 6:50 AM ]

This issue needs work before it will be considered. Do not link outside to minimal cases, you need to provide all the information in the ticket.

Comment by Nikita Prokopov [ 22/Feb/17 7:12 AM ]

David, thanks for the heads up! I’ve updated the issue with standalone zip containing test case and instructions on how to build it. Unfortunately I cannot include cljs.jar in it because it’s too big (24 Mb, while JIRA only allows for 10 Mb attachments max). But I’m sure you have one somewhere on your machine

Comment by David Nolen [ 24/Feb/17 1:38 PM ]

The issue appears to be that somehow duplicate inputs are present, that is

datascript/pull_parser.cljc
will get compiled twice.

Comment by David Nolen [ 24/Feb/17 2:06 PM ]

fixed https://github.com/clojure/clojurescript/commit/04541fbf8ec573d26bac4e4e61e69cb4c64a3dd7

Comment by Nikita Prokopov [ 25/Feb/17 2:35 AM ]

Is it because of how cljc is handled? I don’t see duplicate file names in that repo

Comment by Nikita Prokopov [ 25/Feb/17 2:44 AM ]

BTW confirm that 1.9.494 fixes my issue. Thanks a lot!

Comment by Pavel Kopychenko [ 25/Feb/17 3:59 AM ]

Hi all!! I'm sorry! I have simular error when I try to compile production after update clojurescript to version 1.9.494 from 1.9.229.

Compiling "resources/public/js/c/camerton/testor/main.js" from ["src-cljc" "src-cljs-common" "src-cljs-testor"]...
Feb 25, 2017 3:40:05 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /home/maker/git/camerton/target/cljsbuild-compiler-3/cljs/core/async.js:1426: ERROR - Parse error. No newline allowed before '=>'
var inst_56769 = async(inst_56768);
                                  ^

Feb 25, 2017 3:40:05 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. No newline allowed before '=>' at /home/maker/git/camerton/target/cljsbuild-compiler-3/cljs/core/async.js line 1426 : 34
Comment by António Nuno Monteiro [ 25/Feb/17 10:48 AM ]

@nikita not related to cljc files in particular, just the way we sort dependencies could make us end up with duplicate entries. We now calculate `distinct` by keying on the namespace that the entry provides.

@pavel that's not related to this issue, but I'm also seeing it. Please open a new ticket. It's most likely related to the Closure Compiler upgrade.





[CLJS-1947] cljs.spec "and" passes :cljs.spec/invalid in next spec after failed if there are 4+ sub-specs Created: 19/Feb/17  Updated: 20/Feb/17  Resolved: 20/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Vlad Protsenko Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: bug, clojurescript, spec


 Description   

This bug affects version 1.9.473, but I could not select it in select box, and I did not test it on other versions.

;; This code will print :cljs.spec/invalid once:
(s/conform (s/and pos? println println println) 0)
:cljs.spec/invalid
=> :cljs.spec/invalid

;; This code does not print anything
(s/conform (s/and pos? println println) 0)
=> :cljs.spec/invalid


 Comments   
Comment by Mike Fikes [ 19/Feb/17 9:26 PM ]

Duplicate of CLJS-1935.

Confirmed via git bisect that https://github.com/clojure/clojurescript/commit/ff0b11c123bf46d9e0efff164a7327fb269d2262 fixed the issue reported in this ticket.





[CLJS-1946] Self-hosted: don't emit `goog.require` calls for foreign libs if optimizations different than `:none` Created: 18/Feb/17  Updated: 20/Feb/17  Resolved: 20/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1946.patch    
Patch: Code

 Description   

This is done in JVM CLJS but not in self-hosted.



 Comments   
Comment by David Nolen [ 20/Feb/17 10:53 AM ]

fixed https://github.com/clojure/clojurescript/commit/23beecb7e0b752c98cacebfe0aff3879eab0f0e1





[CLJS-1945] cljs.spec/every-impl kind-fn kind-form dead code Created: 18/Feb/17  Updated: 20/Feb/17  Resolved: 20/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1945.patch    
Patch: Code

 Description   

With Clojure 386e7e6 a [kindfn kindform] let was removed here

https://github.com/clojure/clojure/commit/386e7e63485bcb7bed050df2c2b54a6ceca05e5f#diff-b0f91f319d0c76aadf667da929b08d37L1031

this upstream revision was not copied in ClojureScript 1a297c5 around here:

https://github.com/clojure/clojurescript/commit/1a297c52d958520065335815ffb3dee07c314aa7#diff-5c48ec6d047e1ea6fdcdd00b4f09f45eR729

and is currently dead code that could be removed.



 Comments   
Comment by David Nolen [ 20/Feb/17 11:01 AM ]

fixed https://github.com/clojure/clojurescript/commit/7326d79001f2fbbb2ee4086b1f645cab374c0e58





[CLJS-1944] Can't spec generate non-vector collections Created: 18/Feb/17  Updated: 20/Feb/17  Resolved: 20/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1944.patch    
Patch: Code and Test

 Description   

If you use cljs.spec/coll-of with non-vector :kind, you can't exercise the spec.

Repro:

$ java -jar cljs.jar -m cljs.repl.node
ClojureScript Node.js REPL server listening on 58736
To quit, type: :cljs/quit
cljs.user=> (require '[clojure.spec :as s] 'clojure.test.check.generators)
true
cljs.user=> (s/exercise (s/coll-of string? :kind set?))
Error: Couldn't satisfy such-that predicate after 100 tries.
...


 Comments   
Comment by Mike Fikes [ 18/Feb/17 11:48 AM ]

This is a cut-n-dry defect simply involving missing this Clojure deletion:

https://github.com/clojure/clojure/commit/23e3ec3f8bceeedee70beed7a17846c25eba05a6#diff-b0f91f319d0c76aadf667da929b08d37L1208

in this ClojureScript tracking change here:

https://github.com/clojure/clojurescript/commit/cd43ec9bf40605e230dc8858c2855f9ad85b39d8#diff-5c48ec6d047e1ea6fdcdd00b4f09f45eL702

The consequence is that gen-into is always non-nil (set to []) and then kind is not made use of here: https://github.com/clojure/clojurescript/blob/627f7fd513d928531db48392d8f52142fea5eb38/src/main/cljs/cljs/spec.cljs#L890-L891

Comment by David Nolen [ 20/Feb/17 10:57 AM ]

fixed https://github.com/clojure/clojurescript/commit/77d9077c04f61a19d86e67d18bd7c93217e88aa3





[CLJS-1943] Self-host: `cljs.pprint`'s macros can't be compiled Created: 15/Feb/17  Updated: 20/Feb/17  Resolved: 20/Feb/17

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-1943-2.patch     Text File CLJS-1943-3.patch     Text File CLJS-1943.patch    
Patch: Code and Test

 Comments   
Comment by António Nuno Monteiro [ 15/Feb/17 6:46 PM ]

Attached patch with fix and enabled running the cljs.pprint tests when running the self-parity tests.

Comment by David Nolen [ 20/Feb/17 1:50 PM ]

fixed https://github.com/clojure/clojurescript/commit/6c5fb679bf843bfbd065d0576e1a3d350f11d4b0





[CLJS-1942] Self-host: `cljs.env.macros` and `cljs.analyzer.macros` can't be loaded Created: 14/Feb/17  Updated: 15/Feb/17  Resolved: 15/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-1942.patch    
Patch: Code

 Comments   
Comment by António Nuno Monteiro [ 14/Feb/17 3:50 PM ]

Attached patch with fix.

Comment by David Nolen [ 15/Feb/17 5:41 PM ]

fixed https://github.com/clojure/clojurescript/commit/47cd1cef8f7ed5b16cffc7e2ae4d223328091ab7





[CLJS-1941] `cljs.compiler/cljs-files-in` shouldn't return `.cljc` files if a `.cljs` file exists for the namespace Created: 14/Feb/17  Updated: 24/Feb/17  Resolved: 24/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1941.patch    
Patch: Code

 Description   

We're seeing non-determinism in builds due to this problem. This is the same bug as CLJS-1772, but happens at a different code path.



 Comments   
Comment by António Nuno Monteiro [ 14/Feb/17 12:26 PM ]

Attached patch with fix.

Comment by David Nolen [ 24/Feb/17 1:16 PM ]

fixed https://github.com/clojure/clojurescript/commit/3aa1951533ce2ff7a94f90dbcf74904fe413db48





[CLJS-1940] Undeclared var warning when invoking a protocol method on a `js` interop form Created: 14/Feb/17  Updated: 24/Feb/17  Resolved: 24/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Nicola Mometto Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: interop, protocols, regression


 Description   

Compiling the following code under 1.9.743

(ns test.foo)

(defprotocol Proto
  (f [this]))

(defn foo []
  (f js/Math.E))

Produces the following warning:

WARNING: Use of undeclared Var test.foo/js at line 7 src/test/foo.cljs

This is a regression from 1.9.293

https://github.com/Bronsa/CLJS-1.9.473-regression contains a project set up to reproduce this



 Comments   
Comment by David Nolen [ 24/Feb/17 12:52 PM ]

:advanced
is not the issue here,
:static-fns
is what is required to exhibit the problem.

Comment by David Nolen [ 24/Feb/17 1:05 PM ]

fixed https://github.com/clojure/clojurescript/commit/f43fabc66041eab8399b6d867b481d23615c7c3d





[CLJS-1939] Bad load_file generated for foreign-dep requires on Node Created: 13/Feb/17  Updated: 15/Feb/17  Resolved: 15/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Juho Teperi Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1939-1.patch    

 Description   

After CLJS-1922 ijs :file is preferred as output-path when writing the JS files to output-dir. compiler/load-libs still uses util/relative-name for all cases, which won't work when the JS file is loaded from classpath and written to output-dir using classpath path.

Fix is to use the same logic in load-files to build the path as is used in closure/rel-output-path.



 Comments   
Comment by David Nolen [ 15/Feb/17 5:44 PM ]

fixed https://github.com/clojure/clojurescript/commit/90fc275d939f6c701096378134a930adbd9493f3





[CLJS-1938] :elide-asserts compiler option without effect Created: 13/Feb/17  Updated: 13/Feb/17  Resolved: 13/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

Some self-host related things broke the :elide-asserts compiler option.

cljs.closure/build is the only place that binds *assert* when the :elide-asserts option is set. This however binds the clojure.core dynamic var, the cljs.core/assert macro however uses the cljs.core dynamic var. Therefore this is always true and asserts are never removed.

Possible fixes:
[1] change to cljs.core/*assert*.
[2] change to (core/when core/*assert* ...

I would like to revisit http://dev.clojure.org/jira/browse/CLJS-1494 and always emit the asserts but wrapped in a goog-define so Closure is able to remove them without us actually affecting the generated JS.

[1] https://github.com/clojure/clojurescript/blob/af2ca808fcc5efc088b48957b898fed0b59eddbe/src/main/clojure/cljs/closure.clj#L2091
[2] https://github.com/clojure/clojurescript/blob/af2ca808fcc5efc088b48957b898fed0b59eddbe/src/main/clojure/cljs/core.cljc#L2247



 Comments   
Comment by Thomas Heller [ 13/Feb/17 7:05 AM ]

Sorry for the noise, my conclusion was wrong. Looked at the wrong file.





[CLJS-1937] Self-host: undeclared cljs.core$macros/mod when compiling cljs/core.cljs Created: 12/Feb/17  Updated: 22/Feb/17  Resolved: 22/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1937.patch    
Patch: Code

 Comments   
Comment by António Nuno Monteiro [ 12/Feb/17 11:32 PM ]

Attached patch with fix.

Comment by David Nolen [ 22/Feb/17 6:59 AM ]

fixed https://github.com/clojure/clojurescript/commit/2aa8aae2d8499d1b09a25bfa0b447c46d230cfe0





[CLJS-1936] cljs.analyzer declares vars which are only used in Clojure Created: 11/Feb/17  Updated: 22/Feb/17  Resolved: 22/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1936.patch    
Patch: Code

 Description   

We shouldn't be declaring these vars on the ClojureScript side, as they can lead to runtime errors when trying to call those functions from the self-hosted compiler. Putting them under reader conditionals enables emitting warnings when they are used.



 Comments   
Comment by David Nolen [ 22/Feb/17 6:58 AM ]

fixed https://github.com/clojure/clojurescript/commit/a3a242236e7757a179fd16dd9b86767a73a8cb5d





[CLJS-1935] When calling cljs.spec/valid?, subsequent predicates of cljs.spec/and are evaluated even when early predicate is unsatisfied Created: 11/Feb/17  Updated: 16/Feb/17  Resolved: 15/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Henrik Lundahl Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: clojure.spec

Attachments: Text File CLJS-1935.patch    

 Description   

Affects 1.9.456 and 1.9.473.

The problem is that subsequent predicates of cljs.spec/and are evaluated even when an early predicate is unsatisfied when calling cljs.spec/valid?.

See https://github.com/henriklundahl/minimal-cljs-spec-problem for a minimal example demonstrating the problem.



 Comments   
Comment by David Nolen [ 11/Feb/17 10:49 AM ]

Please do not link outside. Minimal examples need to be in the ticket. This means no project. Just code demonstrating the problem. Thanks.

Comment by Henrik Lundahl [ 12/Feb/17 7:59 AM ]

Since I'm not allowed to edit the description I'll just add the details here.

The following code renders an exception:

(ns asdf
(:require [clojure.spec :as s]))

(defn pred-1? [s]
(> (count s) 100))

(defn pred-2? [s]
(> (count s) 100))

(defn pred-3? [s]
(> (count s) 100))

(s/valid? (s/and string? pred-1? pred-2? pred-3?) "a")

The exception is something like:

Uncaught Error: No protocol method ICounted.-count defined for type cljs.core/Keyword: :cljs.spec/invalid

This works in both Clojure 1.9.0-alpha14 and ClojureScript 1.9.293. It does not work in neither ClojureScript 1.9.456 nor ClojureScript 1.9.473.

Comment by David Nolen [ 15/Feb/17 5:38 PM ]

fixed https://github.com/clojure/clojurescript/commit/ff0b11c123bf46d9e0efff164a7327fb269d2262

Comment by Henrik Lundahl [ 16/Feb/17 12:47 AM ]

Thanks!





[CLJS-1934] Self-host: require-macros :reload / :reload-all fails Created: 09/Feb/17  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-1934.patch    
Patch: Code

 Description   

In a self-hosted environment set up to work with cljs.js/*load-fn*, evaluating an expression like

(require-macros 'foo.core :reload)

fails to request a reload of the code.



 Comments   
Comment by Mike Fikes [ 09/Feb/17 5:55 PM ]

This was caused by a simple typo. With the typo and the example in the description, reloads would be passed in as an empty map instead of reload which would contain the key :reload-macros and the value :reload. Deleting the extra s makes it consistent with the other nearby calls and does the trick.

Comment by David Nolen [ 10/Feb/17 9:45 AM ]

fixed https://github.com/clojure/clojurescript/commit/bf37131c02a393bbfde3da32d2ffd6f878393cb1





[CLJS-1933] Support CLJS browserless remote REPL from nodejs Created: 09/Feb/17  Updated: 09/Feb/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Mike Longworth Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: enhancement, remote, repl
Environment:

Dev machine OSX - build and Cursive editing and REPL
Remote: RaspberryPI - nodejs
compiler out-files shared between devices with OSXFUSE.



 Description   

I would like to develop clojurescript for a remote nodejs target compiling cljs and running a REPL on my development machine.
https://github.com/clojure/clojurescript/wiki/Remote-REPL suggests a way of doing this however:

!) I haven't managed to get this working.
2) I don't like that the solution relies identical absolute file paths for the compiler output, better to have matching relative paths.

I made a post to request help with this but haven't managed to resolve all the issues:
https://groups.google.com/forum/#!topic/clojurescript/Y4ajOcej8Qo

I have made some progress since the post:
1) I dug into the cljs.repl.node source and found I can stop the node hang I reported by specifying repl-env :debug-port, and get:

Clojure 1.8.0
Debugger listening on port 5002
ClojureScript Node.js REPL server listening on 5001
TypeError: Cannot read property 'nameToPath' of undefined
at Object.goog.require (repl:2:49)
at repl:1:-56
at Object.exports.runInThisContext (vm.js:54:17)
at Domain.<anonymous> ([stdin]:50:34)
at Domain.run (domain.js:221:14)
at Socket.<anonymous> ([stdin]:49:25)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at readableAddChunk (_stream_readable.js:146:16)
at Socket.Readable.push (_stream_readable.js:110:10)
TypeError: goog.provide is not a function
at repl:1:-56
at Object.exports.runInThisContext (vm.js:54:17)
at Domain.<anonymous> ([stdin]:50:34)
at Domain.run (domain.js:221:14)
at Socket.<anonymous> ([stdin]:49:25)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at readableAddChunk (_stream_readable.js:146:16)
at Socket.Readable.push (_stream_readable.js:110:10)
at TCP.onread (net.js:523:20)
To quit, type: :cljs/quit

This looks like some kind of path problem but I haven't managed to resolve it.

I did some investigations with my original relative-path setup to try and identify the issues:
1) I eliminated absolute paths from the compile output by disabling analysis caching.
2) I ran wireshark on the REPL port and found that absolute paths were being sent by the REPL, this currently makes the relative path option unworkable.

I have many gaps in my knowledge of the REPL operation at the moment and I don't know what the best approach is to getting a good solution for a browserless remote repl setup.



 Comments   
Comment by David Nolen [ 09/Feb/17 12:33 PM ]

It's probably going to be easier to discuss this issue in IRC or Slack first. There's just too many different issues piled into this one. Thanks.





[CLJS-1932] Self-host: Perf regression macroexpand-check Created: 08/Feb/17  Updated: 09/Feb/17  Resolved: 09/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-1932.patch    
Patch: Code

 Description   

With https://github.com/clojure/clojurescript/commit/cebfb586355b526253fdd25965de976b49a6973e you can observe a compilation perf regression. This is particularly noticeable if you load cljs.core.async (from Andare) into a self-hosted environment (both Lumo and Planck exhibit 2-3x slowdowns).



 Comments   
Comment by Mike Fikes [ 08/Feb/17 11:30 PM ]

With the attached patch, downstream perf in loading cljs.core.async in Planck is confirmed to return to the previous good perf.

Also, confirmed downstream that the change doesn't break the ability to have specs on macros:

With this macros namespace:

(ns foo.core
  (:require [clojure.spec :as s]))

(defmacro add [a b]
  `(+ ~a ~b))

(s/fdef add
  :args (s/cat :a int? :b int?))

The spec works properly downstream in Planck:

cljs.user=> (require-macros 'foo.core)
nil
cljs.user=> (foo.core/add "a" 3)
            ^
Call to foo.core$macros/add did not conform to spec:
In: [0] val: "a" fails at: [:args :a] predicate: int?
:cljs.spec/args  ("a" 3)
 at line 1
cljs.user=> (foo.core/add 2 3)
5
Comment by David Nolen [ 09/Feb/17 5:35 AM ]

fixed https://github.com/clojure/clojurescript/commits/master





[CLJS-1931] Closure Compiler {{--generate_exports}} flag not supported Created: 08/Feb/17  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Stephens Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

We are including a third-party, Closure-compiler compatible JS library in our ClojureScript project, which is using the @export JSDoc-style tags in the source to export names, and another third party JS library (not Closure Compiler compatible) is expecting those names to be exported.

However, the names are not being exported because, we believe, the --generate_exports flag needs to be passed to the Closure Compiler to get it to parse the JSDoc comments and generate goog.export() calls, and there is no interface to enable that flag from the ClojureScript compiler.



 Comments   
Comment by David Nolen [ 10/Feb/17 12:06 PM ]

fixed https://github.com/clojure/clojurescript/commit/af2ca808fcc5efc088b48957b898fed0b59eddbe





[CLJS-1930] Master broken wrt static field: ES5_STRICT_UNCOMMON Created: 06/Feb/17  Updated: 06/Feb/17  Resolved: 06/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1930.patch    
Patch: Code

 Description   

{{git clone https://github.com/clojure/clojurescript}}

cd clojurescript/

script/build

...

+ java -server -cp /Users/mfikes/.m2/repository/org/clojure/clojure/1.8.0/clojure-1.8.0.jar:/Users/mfikes/.m2/repository/com/google/javascript/closure-compiler-unshaded/v20161201/closure-compiler-unshaded-v20161201.jar:/Users/mfikes/.m2/repository/com/google/javascript/closure-compiler-externs/v20161201/closure-compiler-externs-v20161201.jar:/Users/mfikes/.m2/repository/args4j/args4j/2.33/args4j-2.33.jar:/Users/mfikes/.m2/repository/com/google/guava/guava/20.0/guava-20.0.jar:/Users/mfikes/.m2/repository/com/google/protobuf/protobuf-java/3.0.2/protobuf-java-3.0.2.jar:/Users/mfikes/.m2/repository/com/google/code/gson/gson/2.7/gson-2.7.jar:/Users/mfikes/.m2/repository/com/google/code/findbugs/jsr305/3.0.1/jsr305-3.0.1.jar:/Users/mfikes/.m2/repository/com/google/jsinterop/jsinterop-annotations/1.0.0/jsinterop-annotations-1.0.0.jar:/Users/mfikes/.m2/repository/org/clojure/google-closure-library/0.0-20160609-f42b4a24/google-closure-library-0.0-20160609-f42b4a24.jar:/Users/mfikes/.m2/repository/org/clojure/google-closure-library-third-party/0.0-20160609-f42b4a24/google-closure-library-third-party-0.0-20160609-f42b4a24.jar:/Users/mfikes/.m2/repository/org/clojure/data.json/0.2.6/data.json-0.2.6.jar:/Users/mfikes/.m2/repository/org/mozilla/rhino/1.7R5/rhino-1.7R5.jar:/Users/mfikes/.m2/repository/org/clojure/tools.reader/1.0.0-beta3/tools.reader-1.0.0-beta3.jar:/Users/mfikes/.m2/repository/org/clojure/test.check/0.9.0/test.check-0.9.0.jar:/Users/mfikes/.m2/repository/com/cognitect/transit-clj/0.8.285/transit-clj-0.8.285.jar:/Users/mfikes/.m2/repository/com/cognitect/transit-java/0.8.311/transit-java-0.8.311.jar:/Users/mfikes/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.3.2/jackson-core-2.3.2.jar:/Users/mfikes/.m2/repository/org/msgpack/msgpack/0.6.10/msgpack-0.6.10.jar:/Users/mfikes/.m2/repository/com/googlecode/json-simple/json-simple/1.1.1/json-simple-1.1.1.jar:/Users/mfikes/.m2/repository/org/javassist/javassist/3.18.1-GA/javassist-3.18.1-GA.jar:/Users/mfikes/.m2/repository/commons-codec/commons-codec/1.10/commons-codec-1.10.jar:src/main/clojure:src/main/cljs clojure.main script/aot.clj
Exception in thread "main" java.lang.RuntimeException: Unable to find static field: ES5_STRICT_UNCOMMON in class com.google.javascript.jscomp.DiagnosticGroups, compiling:(cljs/closure.clj:98:1)
	at clojure.lang.Compiler.analyze(Compiler.java:6688)
	at clojure.lang.Compiler.analyze(Compiler.java:6625)
	at clojure.lang.Compiler$MapExpr.parse(Compiler.java:3072)
	at clojure.lang.Compiler.analyze(Compiler.java:6677)
	at clojure.lang.Compiler.access$300(Compiler.java:38)
	at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:589)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
	at clojure.lang.Compiler.analyze(Compiler.java:6669)
	at clojure.lang.Compiler.analyze(Compiler.java:6625)
	at clojure.lang.Compiler.eval(Compiler.java:6931)
	at clojure.lang.Compiler.load(Compiler.java:7379)
	at clojure.lang.RT.loadResourceScript(RT.java:372)
	at clojure.lang.RT.loadResourceScript(RT.java:363)
	at clojure.lang.RT.load(RT.java:453)
	at clojure.lang.RT.load(RT.java:419)
	at clojure.core$load$fn__5677.invoke(core.clj:5893)
	at clojure.core$load.invokeStatic(core.clj:5892)
	at clojure.core$load.doInvoke(core.clj:5876)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.core$load_one.invokeStatic(core.clj:5697)
	at clojure.core$load_one.invoke(core.clj:5692)
	at clojure.core$load_lib$fn__5626.invoke(core.clj:5737)
	at clojure.core$load_lib.invokeStatic(core.clj:5736)
	at clojure.core$load_lib.doInvoke(core.clj:5717)
	at clojure.lang.RestFn.applyTo(RestFn.java:142)
	at clojure.core$apply.invokeStatic(core.clj:648)
	at clojure.core$load_libs.invokeStatic(core.clj:5774)
	at clojure.core$load_libs.doInvoke(core.clj:5758)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invokeStatic(core.clj:648)
	at clojure.core$require.invokeStatic(core.clj:5796)
	at clojure.core$require.doInvoke(core.clj:5796)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at user$eval1.invokeStatic(aot.clj:1)
	at user$eval1.invoke(aot.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:6927)
	at clojure.lang.Compiler.load(Compiler.java:7379)
	at clojure.lang.Compiler.loadFile(Compiler.java:7317)
	at clojure.main$load_script.invokeStatic(main.clj:275)
	at clojure.main$script_opt.invokeStatic(main.clj:335)
	at clojure.main$script_opt.invoke(main.clj:330)
	at clojure.main$main.invokeStatic(main.clj:421)
	at clojure.main$main.doInvoke(main.clj:384)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.lang.Var.invoke(Var.java:379)
	at clojure.lang.AFn.applyToHelper(AFn.java:154)
	at clojure.lang.Var.applyTo(Var.java:700)
	at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: Unable to find static field: ES5_STRICT_UNCOMMON in class com.google.javascript.jscomp.DiagnosticGroups
	at clojure.lang.Util.runtimeException(Util.java:221)
	at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7061)
	at clojure.lang.Compiler.analyze(Compiler.java:6648)
	... 47 more


 Comments   
Comment by António Nuno Monteiro [ 06/Feb/17 6:00 PM ]

Attached patch with fix.

Comment by David Nolen [ 06/Feb/17 6:05 PM ]

fixed https://github.com/clojure/clojurescript

Comment by Mike Fikes [ 06/Feb/17 6:09 PM ]

Confirmed that with the patch I can build locally and tests pass.





[CLJS-1929] When expanding libs don't include Hidden files Created: 04/Feb/17  Updated: 06/Feb/17  Resolved: 06/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Bruce Hauman Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1929.patch    

 Description   

When the compiler expands libs that are directories it is including hidden files. The will cause builds to break when editors like Emacs make temp files in the src directories.



 Comments   
Comment by Bruce Hauman [ 04/Feb/17 2:03 PM ]

Providing a simple solution that avoids Hidden files.

Comment by David Nolen [ 06/Feb/17 3:23 PM ]

fixed https://github.com/clojure/clojurescript/commit/182ad1621e2bc4293098dde2f214f5aac4091e75





[CLJS-1928] Self-host: Macro namespace alias in keyword Created: 02/Feb/17  Updated: 24/Feb/17  Resolved: 24/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-1928.patch    
Patch: Code and Test

 Description   

If, in self-hosted ClojureScript you require a macro namespace and establish an alias, as in

(require-macros '[cljs.spec :as s])

You won't be able to use to use the alias in a keyword, as in

::s/foo

The root cause is that when r/*alias-map* is bound to (current-alias-map) this fails to set up mappings for macro namespaces.



 Comments   
Comment by Mike Fikes [ 02/Feb/17 9:27 PM ]

The attached patch revises (current-alias-map) to additionally consult macros namespaces when setting up the alias map. This is tested by adding the (previously-disabled) keyword unit tests, adding a specific test for a macros namespace alias.

(FWIW, a similar technique is also used in Lumo and Planck and, as a consequence, they can properly read forms involving macros namespace aliases, but the resulting forms cannot be compiled in those environments owing to the change needed in cljs.js).

Comment by David Nolen [ 24/Feb/17 1:23 PM ]

fixed https://github.com/clojure/clojurescript/commit/46dcd22713a924bfd90f0a19449bb09f128d11df





[CLJS-1927] Restore ability to refer to foreign libs placed within project-local classpath roots Created: 02/Feb/17  Updated: 04/Feb/17  Resolved: 04/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Chas Emerick Assignee: Chas Emerick
Resolution: Duplicate Votes: 0
Labels: None

Attachments: Text File CLJS-1927.patch    
Patch: Code

 Description   

https://github.com/clojure/clojurescript/commit/97d2d61e78ce747d02d0e5b2ced706f6fb68ec4e changed how relative paths for foreign lib destinations are determined, but made it so that the compiler (at least in some cases) cannot accommodate foreign libs that are defined and sourced from project-local classpath roots (directories, not jars).

This was originally reported and hashed around starting here: https://github.com/bhauman/lein-figwheel/issues/516#issuecomment-275818898

The most minimal case of this I could construct is here: https://github.com/cemerick/figwheel-516 Oddly, bhauman wasn't able to replicate that failing project; even worse, this failure only affects figwheel, not cljsbuild. We've not been able to figure out why that is, but there is one other person on that figwheel issue thread that hit the same problem.

The attached patch does fix my original project's figwheel usage, the minimal case repo I linked above in my testing, and the other contributor's usage in the figwheel issue thread. The change treats file URLs the same as {{java.io.File}}s with regard to calculating relative paths, which AFAICT is most appropriate for the stated objective of the function in question.



 Comments   
Comment by António Nuno Monteiro [ 02/Feb/17 12:03 PM ]

This is probably related to CLJS-1922. We should come up with a solution that solves both problems.

Comment by Chas Emerick [ 02/Feb/17 12:19 PM ]

Yes, CLJS-1922 looks like a related if not equivalent problem. I wish I had found that before filing this.

Comment by David Nolen [ 03/Feb/17 1:39 PM ]

Please check that CLJS-1922 doesn't solve this problem. It's been applied to master.

Comment by Chas Emerick [ 04/Feb/17 7:40 PM ]

Looks good here with CLJS master, closing as dupe of CLJS-1922. Thanks!





[CLJS-1926] Changes to namespace metadata are not properly transferred to *ns* dynamic var Created: 02/Feb/17  Updated: 02/Feb/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

A CLJS macro may want to access the metadata of the current ns via (meta *ns*).

Changes to the ns metadata are not reflected back the *ns* var when re-compiling a namespace, the metadata of the first compile will remain. This is due to the analyzer always calling create-ns but never updating the meta. It should probably be updated inside parse 'ns [1]. Clojure always resets the metadata via the ns macro.

One potential conflict is when a .clj and a .cljs file exist for the same namespace and both provide different metadata. Both platforms reseting the meta is probably not ideal, maybe we should vary-meta merge instead?

[1] https://github.com/clojure/clojurescript/blob/94b4e9cdc845c1345d28f8e1a339189bd3de6971/src/main/clojure/cljs/analyzer.cljc#L2312






[CLJS-1925] Use of undeclared Var cljs.user/RegExp when extending protocol for RegExp Created: 01/Feb/17  Updated: 01/Feb/17  Resolved: 01/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: Juho Teperi Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: None

Attachments: Text File CLJS-1925.patch     Text File CLJS-1925-test-2.patch    
Patch: Code and Test

 Description   

WARNING: Use of undeclared Var schema.core/RegExp at line 356 /home/juho/.boot/cache/tmp/home/juho/Source/**/**/4i8/-uc8bn7/js/main.out/schema/core.cljs
WARNING: Use of undeclared Var bidi.bidi/RegExp at line 232 /home/juho/.boot/cache/tmp/home/juho/Source/**/**/4i8/-uc8bn7/js/main.out/bidi/bidi.cljc

https://github.com/juxt/bidi/blob/master/src/bidi/bidi.cljc#L230
https://github.com/plumatic/schema/blob/master/src/cljx/schema/core.cljx#L355

First commit with problem: https://github.com/clojure/clojurescript/commit/d961e66edfd3d62f80bed18418c597ee1f569e85

Test case by thheller:

(defprotocol X
  (x [x]))

(defprotocol Y
  (y [y]))

(extend-protocol X
  js/RegExp
  (x [x]
    (y x)))

(extend-protocol Y
  js/RegExp
  (y [y]
    :y))


 Comments   
Comment by António Nuno Monteiro [ 01/Feb/17 3:56 PM ]

Attached patch with fix and test.

As specified in the commit message, this is a regression caused by the improper fix to CLJS-1607, which this patch now properly fixes.

Comment by António Nuno Monteiro [ 01/Feb/17 3:59 PM ]

^ The patch I attached is CLJS-1925.patch. The other should be disregarded as it only includes a test.

Comment by David Nolen [ 01/Feb/17 4:02 PM ]

fixed https://github.com/clojure/clojurescript/commit/8c9cde94cb05b3d5446c2e6182b55d6f29893031





[CLJS-1924] The compiler cannot infer the target type of "(. RecordName -prototype)" expressions Created: 01/Feb/17  Updated: 01/Feb/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Viktor Magyari Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: compiler, extern


 Description   

Repro:

Place

(set! *warn-on-infer* true)

(defrecord Foo [])

anywhere in your source files, compile with :infern-externs true.

Expected:

Multiple warnings like:

  • WARNING: Cannot infer target type in expression (. Foo -prototype)
  • WARNING: Cannot infer target type in expression (. other__8838__auto__ -constructor)
  • WARNING: Cannot infer target type in expression (. user/Foo -getBasis)

There are also warnings for (. cljs.core/List -EMPTY), but this might be unrelated.






[CLJS-1923] Optimization causes TypeError not a function with a simple three.js dependency Created: 01/Feb/17  Updated: 06/Feb/17  Resolved: 06/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.293
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Plumpton Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: cljs, compiler
Environment:

Ubuntu 16.10, Clojurescript 1.9.456


Attachments: GZip Archive problem.tar.gz    

 Description   

I've created a simple test case that creates a three.js renderer and calls one function on loading (.setSize renderer 200 200)

When building with "lein cljsbuild once dev" everything works when the browser loads index.html.

But with "lein cljsbuild once min" an error occurs on loading:
"Uncaught TypeError: (intermediate value).bc is not a function"



 Comments   
Comment by David Plumpton [ 04/Feb/17 6:17 PM ]

Sorry, misunderstanding of externs behaviour, please close.





[CLJS-1922] uti/relative-name presumes that local foreign-lib files are under working directory which is not true on Boot Created: 30/Jan/17  Updated: 03/Feb/17  Resolved: 03/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Juho Teperi Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

Cljs 1.9.456, Boot-cljs


Attachments: Text File CLJS-1922-1.patch    

 Description   

cljs.util/relative-name presumes that foreign-libs are located under working directory.

This is not true on Boot with local deps.cljs and foreign-libs. In Boot files from source/resource-paths are copied into temp directories (outside of working directory), and classpath contains these temp directories.

I'm investigation two solutions:

Improve relative-name to return paths relative to a classpath directory under which the file is found. Path relative to a classpath directory should be unique enough for output path, as foreign library contents are anyway read from classpath (unless I'm mistaken).

Another solution I'll check, is why the paths need to be relativized, in most cases foreign-lib `:file` value is relative.



 Comments   
Comment by Juho Teperi [ 30/Jan/17 7:07 PM ]

Solution using :file as output path if it is set and is relative. Else falls back to the current behavior.

Comment by David Nolen [ 03/Feb/17 1:39 PM ]

fixed https://github.com/clojure/clojurescript/commit/f7f2142d44a2bddbb74bdabaf45ba032ad452c53





[CLJS-1921] Certain files are compiled twice, leading to "Can't redefine a constant ..." errors Created: 30/Jan/17  Updated: 24/Feb/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Viktor Magyari Assignee: Viktor Magyari
Resolution: Unresolved Votes: 0
Labels: compiler
Environment:

windows, linux



 Description   

Repro:

Create a folder with the following files:

cljs.jar (the quick start uberjar)
src
  foo.cljc
  core.cljc

The contents shall be:

;; foo.cljc
(ns foo)

(def ^:const a 10)

;; core.cljc
(ns core
  (:require [foo]))

(def ^:const a 10)

In this folder, call java -cp src;cljs.jar clojure.main. In the repl, enter:

(require '[cljs.build.api :refer [build]])
(build "src" {:output-to "out/main.js" :output-dir "out" :verbose true})

If some conditions are met (see [1] and the explanations below), you'll see the compilation fail with "Can't redefine a constant at <...>".

NOTE: the easiest way to reproduce is to sort the value returned by cljs.closure/add-dependency-sources by a function of our choosing, (comp first :provides) for example. This can ensure that the last element will be a dependency which appears twice (see explanations below). However, in this case we have to use a hand-crafted classpath, which includes our patched clojurescript jar (+ its dependencies, + the src folder).

Cause:

NOTE: My understanding of the compiler internals (cljs.js-deps and cljs.closure in particular) is very superficial, but those familiar with it can probably follow along.

The journey starts at cljs.closure/add-dependency-sources, invoked in cljs.closure/build. The function takes some dependencies, converts them to a set, and adds some dependencies to it. Things to note here:

  • the :file entry in each dependency is nil [0]
  • the order of (seq (set inputs)) is "random" (or unspecified rather) [1]
  • the :source-file entry in each dependency is a java.io.File instance
  • the :source-file entry in each additional dependency from cljs.closure/find-cljs-dependencies is a java.net.URL instance
  • there are some dependencies (in the repro case at least) which were in inputs and were added as well with cljs.closure/find-cljs-dependencies (so they appear twice in the list)

The fact that some dependencies are java.io.File, some are java.net.URL instances may be the reason why some items appear multiple times in the set, but I haven't confirmed this.

Next, the computed dependencies are fed into cljs.js-deps/dependency-order, where they are passed to cljs.js-deps/build-index. This function reduces over each dependency (OUTER reduce), and reduces over each provided namespace (:provides entry, INNER reduce).

Here's the crucial part: the INNER reduce associates each namespace in :provides with the dependency, and the OUTER reduce then associates the :file entry with the dependency. But, since the :file entries are nil (see [0]), the value mapped to nil is overridden with each step in the OUTER reduce. Now, let X be a dependency which appeared twice (or at least twice, does not matter) in inputs. If X happens to be the last element of the dependencies (depends on [1]), then in the final map (when the OUTER reduce finishes) X will be mapped to nil. Therefore, in the final index, X will be present twice (once mapped to nil, once mapped to the namespace it provides).

Afterwards, these dependencies are compiled, and when the stars align (= sometimes it happens, sometimes it doesn't, both with parallel and non-parallel build) the compilation will fail with "Can't redefine a constant at <...>". This is most likely due to the fact that certain dependency (X), which has a ^:const var, was compiled twice (and some namespaces are compiled twice, this can be observed when :verbose is set to true).

I could reproduce the error on both windows (locally), and on linux (on a travis-ci server).



 Comments   
Comment by David Nolen [ 24/Feb/17 2:44 PM ]

Please verify that CLJS-1948 does or does not resolve this problem.





[CLJS-1920] cljs.build.api/node-inputs: package.json files are only added if module entries are top-level Created: 30/Jan/17  Updated: 01/Feb/17  Resolved: 01/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1920.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 01/Feb/17 10:29 AM ]

fixed https://github.com/clojure/clojurescript/commits/master





[CLJS-1919] cljs.spec conformer regression Created: 30/Jan/17  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Allan Jiang Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Upon compiling the following code,

(ns repro.core
  (:require [cljs.spec :as s]))

(defn coll->set [x] 
  (cond
    (set? x) x
    (coll? x) (set x)
    :else ::s/invalid))

(s/def ::set-ints (s/coll-of int? :kind (s/conformer coll->set) :into #{}))
(s/def ::vec-ints (s/coll-of int? :kind vector? :into []))
(try
  (s/valid? ::set-ints [1 2 3]) 
  (catch js/Object e
    (js/console.error e)))
(s/valid? ::vec-ints [1 2 3])

the validation for ::set-ints fails due to using the conformer.

The error message is:

TypeError: cljs.spec.spec_impl.call(...).call is not a function
    at core.cljs:10
    at cljs.spec.every_impl.cljs$core$IFn$_invoke$arity$4.cljs.spec.t_cljs$spec860.cljs$spec$Spec$conform_STAR_$arity$2 (spec.cljs:844)
    at cljs$spec$conform_STAR_ (spec.cljs:40)
    at Function.cljs.spec.valid_QMARK_.cljs$core$IFn$_invoke$arity$2 (spec.cljs:357)
    at cljs$spec$valid_QMARK_ (spec.cljs:353)
    at core.cljs:13


 Comments   
Comment by David Nolen [ 10/Feb/17 11:59 AM ]

As far as I can tell this not a bug, it doesn't work in Clojure 1.9.0-alpha14





[CLJS-1918] case needs a type hint for keywords case when using *warn-on-infer* Created: 30/Jan/17  Updated: 30/Jan/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: Next
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None





[CLJS-1917] `case` doesn't handle matching against lists Created: 28/Jan/17  Updated: 28/Jan/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The following works in Clojure but not ClojureScript

(let [foo '(:a :b)]
  (case foo
    '(:a :b) :works))





[CLJS-1916] __dirname and __filename are not defined when compiling for Node.js with optimizations :none Created: 28/Jan/17  Updated: 28/Jan/17  Resolved: 28/Jan/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1916.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 28/Jan/17 2:08 PM ]

fixed https://github.com/clojure/clojurescript/commit/ba205f0d091cd541c241a5d0e9419cbf3e4e8808





[CLJS-1915] cljs.test: Index out of bounds for stack element w/o line/column Created: 28/Jan/17  Updated: 28/Jan/17  Resolved: 28/Jan/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1915.patch    
Patch: Code and Test

 Description   

The cljs.test/js-line-and-column function does not properly handle stack elements that have no line and column information encoded in them. In particular, if you pass in something like "eval@[native code]" (which can be part of a stack from JavaScriptCore), you will get an index out of bounds exception.



 Comments   
Comment by David Nolen [ 28/Jan/17 11:11 AM ]

fixed https://github.com/clojure/clojurescript/commit/2f8a1529955acc943ac8082ab5848b2cba54bc4d





[CLJS-1914] Investigate directly requiring CommonJS Node module into a ClojureScript namespace Created: 28/Jan/17  Updated: 28/Jan/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: Next
Fix Version/s: None

Type: Task Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Comments   
Comment by David Nolen [ 28/Jan/17 10:20 AM ]

We would need to check that it exists. We would also need to parse out CommonJS requires to sort out the foreign libs inputs.





[CLJS-1913] Investigate slow reading / compilation of CLJC files Created: 27/Jan/17  Updated: 27/Jan/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None





[CLJS-1912] cljs.build.api/node-modules Created: 27/Jan/17  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: Next
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Comments   
Comment by David Nolen [ 10/Feb/17 10:58 AM ]

fixed in 1.9.456





[CLJS-1911] Need to bind Node.js require Created: 27/Jan/17  Updated: 27/Jan/17  Resolved: 27/Jan/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Critical
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1911.patch    
Patch: Code

 Description   

While making an ostensibly simple change for CLJS-1910, updating from cljs.nodejs/require to js/require, it was discovered that Node was, initially inexplicably, indicating that require wasn't available at runtime.

Credit to António: He discovered the root cause, potential serious ramifications, and a potential patch (attached to this ticket). See more detailed commentary from António here: http://dev.clojure.org/jira/browse/CLJS-1910?focusedCommentId=44906&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44906

The attached patch is sufficient to allow the patch attached to CLJS-1910 pass script/test-self-parity.

Given the subtleties surrounding this issue, this patch probably warrants review.



 Comments   
Comment by David Nolen [ 27/Jan/17 9:02 AM ]

fixed https://github.com/clojure/clojurescript/commit/35bcfce2565148cd96b31499a2bbc3bfc2257822





[CLJS-1910] Self-host: Need to eliminate use of cljs.nodejs/require Created: 26/Jan/17  Updated: 27/Jan/17  Resolved: 27/Jan/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-1910.patch    
Patch: Code

 Description   

Need to change this:

https://github.com/clojure/clojurescript/blob/master/src/test/self/self_parity/test.cljs#L56



 Comments   
Comment by António Nuno Monteiro [ 27/Jan/17 12:50 AM ]

The change from `require` to `nodeGlobalRequire` in this commit
https://github.com/clojure/clojurescript/commit/59a7f265fac02c931cc3d5615727da861db62e3b#diff-db201d3634488851510ee2fbce327924R75
means that loading every file will go through `vm.runInThisContext`.

The above causes `require` to not be bound, since `require` is a "free variable" and not a property of the global object (more context here https://github.com/nodejs/node-v0.x-archive/issues/9211#issuecomment-134412415).

A suggested fix is to add `global.require = require;` to `cljs/bootstrap_node.js`. I tested that fix and it worked.

Note that this is not only breaking the self-host tests. It will break every ClojureScript build which targets Node.js under `:none` optimizations, which should therefore be considered critical.

Comment by Mike Fikes [ 27/Jan/17 1:18 AM ]

The attached patch addresses (and only addresses) the primary issue in this ticket: The need to use js/require.

Given the critical and subtle nature of the side issue discovered and detailed in António's comment above, that issue is split off to CLJS-1911 in case some other more appropriate solution is found for it.

Comment by David Nolen [ 27/Jan/17 9:20 AM ]

fixed by removing the breaking change https://github.com/clojure/clojurescript/commit/18d1e5792f6c712b6c8e426ac9123ee4b898a374, CLJS-1911 was the root cause





[CLJS-1909] Self-host: circular dependency when requiring cljs.reader Created: 26/Jan/17  Updated: 26/Jan/17  Resolved: 26/Jan/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1909.patch    
Patch: Code

 Description   

`cljs.analyzer` -> `cljs.reader` -> `cljs.reader$macros` -> `cljs.analyzer`



 Comments   
Comment by David Nolen [ 26/Jan/17 11:32 PM ]

fixed https://github.com/clojure/clojurescript/commit/7de568f7c80ce5f2a41222063251f0ecf688c3e2





[CLJS-1908] Improve error messages by using pr-str instead of str when printing objects Created: 26/Jan/17  Updated: 26/Jan/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Daniel Compton Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: errormsgs


 Description   

Many error messages from ClojureScript include the invalid argument like this:

(throw (js/Error. (str "Doesn't support name: " x)))

If x is nil, then the error message produces is "Doesn't support name: " which is a bit mystifying to debug. If x was wrapped with pr-str then the error message would be the much more understandable: "Doesn't support name: nil".

If there's interest in this, then I can prepare a patch which wraps these kinds of errors with pr-str.






[CLJS-1907] Improve error message from cljs.reader/read-string when reading keyword with number first (e.g. :0seconds) Created: 26/Jan/17  Updated: 26/Jan/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Daniel Compton Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: errormsgs

Attachments: Text File CLJS-1907.patch    

 Description   

In read-keyword, if the keyword doesn't match symbol-pattern then re-matches* returns nil, and then the aget for token throws an error about null not being an object. The provided patch checks if the keyword matches, and if not throws an error with a descriptive error message that the keyword is not valid.

This hit our team when we were trying to deserialise some EDN, and we had keywords with leading numbers in them.

(defn read-keyword
  [reader initch]
  (let [token (read-token reader (read-char reader))
        a (re-matches* symbol-pattern token) ;; returns nil when token is `0s`
        token (aget a 0) ;; throws from aget on nil
        ns (aget a 1)
        name (aget a 2)]
    (if (or (and (not (undefined? ns))
                 (identical? (. ns (substring (- (.-length ns) 2) (.-length ns))) ":/"))
            (identical? (aget name (dec (.-length name))) ":")
            (not (== (.indexOf token "::" 1) -1)))
      (reader-error reader "Invalid token: " token)
      (if (and (not (nil? ns)) (> (.-length ns) 0))
        (keyword (.substring ns 0 (.indexOf ns "/")) name)
        (keyword token)))))


 Comments   
Comment by Daniel Compton [ 26/Jan/17 6:05 PM ]

I don't love using the _ side effect in the let binding, but the alternative makes the code a bit uglier and less readable.





[CLJS-1906] Self-host: script/test-self-parity fails Created: 25/Jan/17  Updated: 26/Jan/17  Resolved: 26/Jan/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-1906.patch    

 Description   

With master as of the writing of this ticket

script/test-self-parity fails with:

#error {:message "Could not parse ns form cljs.clojure-alias-test", :data {:tag :cljs/analysis-error}, :cause #object[Error Error: No protocol method IDeref.-deref defined for type null: ]}


 Comments   
Comment by David Nolen [ 26/Jan/17 10:10 PM ]

fixed https://github.com/clojure/clojurescript/commit/f4e057c7742861d48568b776024d142f68143fac





[CLJS-1905] Self-host: Stacktraces for script/test-self-parity Created: 25/Jan/17  Updated: 06/Feb/17  Resolved: 06/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-1905-2.patch     Text File CLJS-1905.patch    
Patch: Code

 Description   

If script/test-self-parity fails, you currently only get a prn of the error, which makes it difficult to locate the cause of the error. Add some infrastructure to print stacktraces.



 Comments   
Comment by Mike Fikes [ 05/Feb/17 12:29 PM ]

Previous patch no longer applies; attaching re-baselined patch.

Comment by David Nolen [ 06/Feb/17 3:22 PM ]

fixed https://github.com/clojure/clojurescript/commit/c4348d4a8187062b3f0023f5256d2f19d9371474





[CLJS-1904] Reload support for JS Modules Created: 25/Jan/17  Updated: 25/Jan/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: Next
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Process modules currently works by changing transforming compiler opts. This means the resulting compiler opts cannot be used to run JS module processing again. This issue is now clear in cljs/repl.cljc. The other issue is that JS module processing is the only time that ClojureScript is involved in the compilation of JS sources - prior to this we never to need to trigger JS compilation ourselves. Thus require + :reload doesn't work on JS namespaces.






[CLJS-1903] Remove anonymous vars from dir and apropos output Created: 24/Jan/17  Updated: 25/Jan/17  Resolved: 25/Jan/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1903.patch    
Patch: Code

 Description   

Anonymous vars (associated with reify gensyms) appear in dir output. For example, the trailing end of (dir cljs.spec) looks like:

...
spec-impl
spec?
t_cljs$spec3750
t_cljs$spec3780
t_cljs$spec3821
t_cljs$spec3836
t_cljs$spec3854
t_cljs$spec3867
t_cljs$spec3874
t_cljs$spec3970
t_cljs$spec3973
t_cljs$spec3984
t_cljs$spec3987
t_cljs$spec4003
t_cljs$spec4253
t_cljs$spec4256
t_cljs$spec4266
t_cljs$spec4272
tuple-impl
unform
unform*
valid?
with-gen
with-gen*

(For comparison, items like these don't appear in the Clojure REPL for dir output.)

This ticket requests that these be removed from dir as well as apropos as being noise / distraction.



 Comments   
Comment by Mike Fikes [ 24/Jan/17 11:03 PM ]

In addition to the example in the description, with the attached patch:

cljs.user=> (apropos spec)
(cljs.core/special-symbol? cljs.core/specify cljs.core/specify! 
cljs.spec/*fspec-iterations* cljs.spec/->t_cljs$spec3750 
cljs.spec/->t_cljs$spec3780 cljs.spec/->t_cljs$spec3821 
cljs.spec/->t_cljs$spec3836 cljs.spec/->t_cljs$spec3854 
cljs.spec/->t_cljs$spec3867 cljs.spec/->t_cljs$spec3874 
cljs.spec/->t_cljs$spec3970 cljs.spec/->t_cljs$spec3973 
cljs.spec/->t_cljs$spec3984 cljs.spec/->t_cljs$spec3987 
cljs.spec/->t_cljs$spec4003 cljs.spec/->t_cljs$spec4253 
cljs.spec/->t_cljs$spec4256 cljs.spec/->t_cljs$spec4266 
cljs.spec/->t_cljs$spec4272 cljs.spec/and-spec-impl 
cljs.spec/fspec-impl cljs.spec/get-spec cljs.spec/map-spec 
cljs.spec/map-spec-impl cljs.spec/merge-spec-impl 
cljs.spec/multi-spec-impl cljs.spec/or-spec-impl 
cljs.spec/regex-spec-impl cljs.spec/spec-impl cljs.spec/spec? 
cljs.spec/t_cljs$spec3750 cljs.spec/t_cljs$spec3780 
cljs.spec/t_cljs$spec3821 cljs.spec/t_cljs$spec3836 
cljs.spec/t_cljs$spec3854 cljs.spec/t_cljs$spec3867 
cljs.spec/t_cljs$spec3874 cljs.spec/t_cljs$spec3970 
cljs.spec/t_cljs$spec3973 cljs.spec/t_cljs$spec3984 
cljs.spec/t_cljs$spec3987 cljs.spec/t_cljs$spec4003 
cljs.spec/t_cljs$spec4253 cljs.spec/t_cljs$spec4256 
cljs.spec/t_cljs$spec4266 cljs.spec/t_cljs$spec4272)

becomes much more useful:

cljs.user=> (apropos spec)
(cljs.core/special-symbol? cljs.core/specify cljs.core/specify! 
cljs.spec/*fspec-iterations* cljs.spec/and-spec-impl 
cljs.spec/fspec-impl cljs.spec/get-spec cljs.spec/map-spec 
cljs.spec/map-spec-impl cljs.spec/merge-spec-impl 
cljs.spec/multi-spec-impl cljs.spec/or-spec-impl 
cljs.spec/regex-spec-impl cljs.spec/spec-impl cljs.spec/spec? 
cljs.spec/specize*)
Comment by David Nolen [ 25/Jan/17 5:01 PM ]

fixed https://github.com/clojure/clojurescript/commit/a64ab2c975bcc000fd10b4b485b4ba4259e70276





[CLJS-1902] Add support for compiler option :inline-source-maps Created: 24/Jan/17  Updated: 01/May/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None

Patch: Code and Test

 Description   

1. refactor `emit-source-map` and break it into multiple functions
2. fix logic for relative path computation (see `strip-prefix-path`)
3. add support for `:inline-source-maps` option
4. add tests

Related: CLJS-1402, CLJS-1901



 Comments   
Comment by Antonin Hildebrand [ 24/Jan/17 8:09 PM ]

Patches:
https://github.com/darwin/clojurescript/commit/de1da63072c8049b9812d41cce750e5a972c0b0b.patch
https://github.com/darwin/clojurescript/commit/2389fb7839a18299d842d381b135a669a7091869.patch
https://github.com/darwin/clojurescript/commit/3ba594d8c7215ef8c8276737b7e5d8008c6b3a98.patch

Comment by Antonin Hildebrand [ 24/Jan/17 8:27 PM ]

Full review: https://github.com/clojure/clojurescript/compare/darwin:inline-source-maps~3...darwin:inline-source-maps

Also please note that the first patch testing original functionality fails in one test because there was a bug in timestamp formatting in :source-map-url case:
https://github.com/clojure/clojurescript/compare/master...dar