This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-03
Channels
- # beginners (50)
- # cider (6)
- # cljdoc (2)
- # cljs-dev (19)
- # clojars (2)
- # clojure (20)
- # clojure-dev (35)
- # clojure-italy (2)
- # clojure-norway (12)
- # clojure-uk (17)
- # clojurescript (7)
- # data-science (3)
- # datomic (10)
- # emacs (2)
- # events (1)
- # figwheel-main (2)
- # fulcro (8)
- # graphql (1)
- # juxt (3)
- # nrepl (4)
- # off-topic (23)
- # parinfer (1)
- # pathom (63)
- # re-frame (7)
- # reagent (1)
- # reitit (5)
- # ring-swagger (1)
- # shadow-cljs (23)
- # tools-deps (16)
I found one regression with speculative (https://github.com/slipset/speculative) which I can reproduce as follows:
;; run with:
;; clj -Srepro -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.439"} org.clojure/test.check {:mvn/version "RELEASE"}}}' -m cljs.main -re node -i callstack.cljs
(ns callstack
(:require
[clojure.test.check]
[clojure.spec.alpha :as s]
[clojure.spec.test.alpha :as stest]
[clojure.test :as t]
))
(s/fdef clojure.core/=
:args (s/+ any?)
:ret boolean?)
(t/deftest =-test
(stest/instrument)
(= 1))
(t/run-tests)
(println "done, exiting...")
Error: RangeError: Maximum call stack size exceeded
Used to work on 339.FWIW, the challenge with CLJS-2956 above is that, inside the instrumented function “wrapper,” it ultimately calls apply
on the plain version in order to invoke it, but with instrumentation re-enabled. The intent is to catch anything that the function itself calls. But, the instrumentation is also enabled during the mechanics of apply
. So anything instrumented that is called indirectly via apply
—in this case, =
—can cause infinite recursion.
@mfikes I had a similar issue here https://github.com/slipset/speculative/blob/master/src/speculative/test.cljc#L81
First I manually unstrumented =
, but later I decided to wrap it in a with-instrument-disabled
, which did the trick.
@borkdude In this case, apply
ultimately ends up calling =
here https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L7067
With 1.10.339 we were using MultiFn
to “overwrite various arities, and with 1.10.439, we are overwriting existing arities in a bespoke fashion, and this causes subtle differences in call patterns.
I think you can still effectively run into the same sort of issue with 1.10.339, but with slightly different scenarios (if you spec apply
itself, for example).
we’re already doing that: https://github.com/slipset/speculative/blob/master/src/speculative/core.cljc#L16
ah, but we didn’t enable the test for it, because we ran into https://dev.clojure.org/jira/browse/CLJS-2942
The fundamental problem, as I see it, is that since the “wrapper” is implemented using ClojureScript, and a lot of the JavaScript code that is emitted in order to support the function dispatch machinery is also implemented by calling on ClojureScript core functions, it becomes meta-circular very quickly when you introduce the concept of specing core functions—and sometimes leads to infinite recursion.
A corollary: https://dev.clojure.org/jira/browse/CLJS-2956 and similar tickets may only affect projects that attempt to spec core functions. “Regular” projects that spec their own non-core functions may be immune to this class of issues.
I wonder why we didn’t see this when instrumenting a lot of core functions and then running coal-mine?
looks like there is an externs inference regression in 1.10.439. https://dev.clojure.org/jira/browse/CLJS-2957
I saw AST changes happened. Are they for the compiler state? I am worried about tooling maintainers (I am the last committer of cljs-tooling
). Is there a place where these changes are summarized if breaking?
https://dev.clojure.org/jira/browse/CLJS-1461 depending on how much of the AST you use some of the changes are breaking (renamed :op
for example)
Thank you will check that
Looks like what I am looking for so thanks for the link once again