@dnolen fyi, I'm working towards a release of core.async next week, but of course, we can always do another one :)

A good one to assess prior to release: https://clojure.atlassian.net/projects/CLJS/issues/CLJS-3170 TL;DR: The particular example is minor, but generally illustrates an issue in that we will start inferring Array for Closure libraries, where the compiler understands array

@mfikes just curious do you know which patch in patch tender responsible for this warning? https://travis-ci.org/binaryage/cljs-oops/builds/607167428#L868

I briefly looked at the list and didn’t see it, but don’t spend time on it if you don’t know from top of your head

A hunch is that it is an incorrect diagnostic triggered by the patch in CLJS-2823

But that ticket evidently passed Canary… hrm. Let me run it through Canary again.

thanks, it was reported by cljs-oops tests but it is an issue in cljs-devtools lib, I tried to work around it by going through js/: https://gist.github.com/darwin/f4704eb6f0b65ea28a38351a10b451b6 which seems to silence the warning when compiled with latest patch-tender

Ahh, so you are using set! there… seems like it could be related then. (My initial hunch is that the compiler is wrong and you shouldn’t need to use js/ to workaround.)

I assume the source of the warning is here: https://github.com/google/closure-library/blob/master/closure/goog/async/nexttick.js#L137 you are newly able to understand the GCL annotations and see that the goog.async.nextTick.setImmediate_ is private

Ah… wow! That’s cool!

it is welcome, but as a lib I have no control over user’s compiler warning prefs, so I need a workaround, the js/ approach seems to work, I don’t care about advanced mode in this case

cljs.user=> (require '[goog.async.nextTick :as next-tick])
nil
cljs.user=> next-tick/setImmediate_
WARNING: var: goog.async.nextTick/setImmediate_ is not public at line 1 <cljs repl>

^ repro from current master 🙂

oh, so now I’m a bit puzzled, if the patch is already included in cljs master, why cljs-oops didn’t fail in canary, only with patch-tender?

Because private var accesses are currently suppressed in set! on master

CLJS-2823 eliminates that suppression

ok, thanks for clarification, and now I understand why I wasn’t able to find the patch by glancing over the list 🙂

Mechanical testing FTW

For the Array vs. array issue, I’ve marked https://clojure.atlassian.net/projects/CLJS/issues/CLJS-3170 as a blocker to remind us to assess it before release