Shared AOT cache: Avoid referring to cache directory in analyzer warnings

Question

If an analysis warning is emitted for code in a JAR, the warning will include the AOT cache path.

For example, with

`
(ns foo.core)

(inc "a")
`

in {{foo.jar}}, loading this code will cause a diagnostic that includes the AOT cache path in the message:

WARNING: cljs.core/+, all arguments must be numbers, got [string number] instead. at line 3 /Users/mfikes/.cljs/.aot_cache/1.10.126/47C5358/foo/core.cljs

Perhaps in this case it would be better to indicate just a classpath-relative filename

WARNING: cljs.core/+, all arguments must be numbers, got [string number] instead. at line 3 @/foo/core.cljs

or if possible, even using a JAR file url like this

WARNING: cljs.core/+, all arguments must be numbers, got [string number] instead. at line 3 jar:file:///foo.jar!/foo/core.cljs

To repro, first create {{foo.jar}} using the following command, with the {{foo.core}} namespace in {{foo/core.cljs}}:

jar cvf foo.jar foo

Then use the 1.10.126 uberjar (renamed to {{cljs-1.10.126.jar}} here) to launch a Node REPL:

java -cp cljs-1.10.126.jar:foo.jar clojure.main -m cljs.repl.node

and evaluate

(require 'foo.core)

To see what you get with 1.9.946, remove the {{.cljs_node_repl}} directory and using the 1.9.946 uberjar (renamed to {{cljs-1.9.946.jar}} here):

java -cp cljs-1.9.946.jar:foo.jar clojure.main -m cljs.repl.node

In this case, {{(require 'foo.core)}} still refers to the local cache directory

WARNING: cljs.core/+, all arguments must be numbers, got [string number] instead. at line 3 .cljs_node_repl/foo/core.cljs

but this somehow seems less problematic when compared to exposing the user to the shared AOT cache path.

Answer 1

_Comment made by: mfikes_

The attached patch

# Revises a few of the {{Compilable}} extensions (to {{File}}, {{URL}}, and {{String}}) to add {{:origin-file}} to the {{opts}} (merging {{opts}} last so that any {{:origin-file}} already in {{opts}} is maintained)
# Adds a new {{ana/\*origin-file\*}} dyn var to go along with {{ana/\*cljs-file\*}}, binding it to the value of {{(:origin-file opts)}}
# Updates the code that renders error messages to use {{ana/\*origin-file\*}} in preference to {{ana/\*cljs-file\*}}

This has the effect of pointing to the original source of the error rather than to the on-disk copy in a cache (local or shared).

For, example, with the analysis error originating from a file in a JAR, you see:


cljs.user=> (require 'foo.core)
WARNING: cljs.core/+, all arguments must be numbers, got [string number] instead. at line 3 jar:file:/private/tmp/test-origin-file/foo.jar!/foo/core.cljs


Another illustrative example: Using

{code:title=deps.edn}
{:deps {org.clojure/clojurescript {:mvn/version "1.10.132"}
        com.cerner/clara-rules {:mvn/version "0.17.0"}}}


master produces this (elided for brevity):


clj -Srepro -m cljs.main -re node -e "(require 'clara.rules)"

WARNING: macroexpand already refers to: cljs.core/macroexpand being replaced by: clojure.reflect/macroexpand at line 33 /Users/mfikes/.cljs/.aot_cache/1.10.132/3837055/clojure/reflect.cljs
WARNING: Use of undeclared Var schema.core/MapEntry at line 239 /Users/mfikes/.cljs/.aot_cache/1.10.132/2E9D363/schema/core.cljs
WARNING: Wrong number of args (3) passed to MapEntry at line 759 /Users/mfikes/.cljs/.aot_cache/1.10.132/2E9D363/schema/core.cljs


while the patch, built as 1.10.133 produces more informative error pointers into the actual source JARs instead of the AOT cache directory


WARNING: macroexpand already refers to: cljs.core/macroexpand being replaced by: clojure.reflect/macroexpand at line 33 jar:file:/Users/mfikes/.m2/repository/org/clojure/clojurescript/1.10.133/clojurescript-1.10.133.jar!/clojure/reflect.cljs
WARNING: Use of undeclared Var schema.core/MapEntry at line 239 jar:file:/Users/mfikes/.m2/repository/prismatic/schema/1.1.6/schema-1.1.6.jar!/schema/core.clj
WARNING: Wrong number of args (3) passed to MapEntry at line 759 jar:file:/Users/mfikes/.m2/repository/prismatic/schema/1.1.6/schema-1.1.6.jar!/schema/core.cljs

Answer 2

Comment made by: dnolen

Yeah this is a REPL specific problem. I think the right way to handle this is to fix how REPLs compile code. Currently they do an analysis pass in reverse fashion instead of just putting everything in dependency order and compiling in that order same as build. This would be a good opportunity to clean up some old code paths that only the REPLs use.

Answer 3

Reference: https://clojure.atlassian.net/browse/CLJS-2615 (reported by mfikes)