-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for multi src path analysis #28
Comments
One problem with the approach outlined above is that it analyzes source roots in sequence, building up compiler state. This is fine if the source roots are analyzed in an order consistent with their dependency relation, but it doesn't work if the source roots are analyzed in an arbitrary order. Somehow, the ordering of |
When building with |
I can no longer reproduce this issue. I did the due diligence of attempting to revert back to the versions of the releases that existed at the time I wrote this issue in order to reproduce it, with no success. So, I'll close this issue now. |
This actually still occurs; not sure why I failed to reproduce it earlier. In fact, it appears with the latest ClojureScript compiler ( |
I've created a reduction in the form of a minimal repository illustrating the problem: https://github.com/mfikes/weasel-src-paths |
I found that, by adding the additional source path to the project-level |
Weasel uses the clojurescript compiler to analyze source for completion or something. Analysis seems to depend on all clojurescript being under a single directory and for cljs directories to be listed in the top level :source-paths key of the leingingen project.clj. Also renamed resolve to resolve-url to keep it from conflicting with clojure.core/resolve. nrepl/weasel#28
* Make Weasel startup nearly instantly * Remove flaky server-side tracking of loaded libraries in favor of client-side. * Lean on `goog.require` in the client for loading namespaces. Weasel is now essentially a dumb pipe between the client and piggieback with some evaluation and compilation, respectively, on either end. There may be some issues with leaning on `goog.require` in certain environments, however. See Mike Fikes's comment here: #37 (comment) cc #47 #28 (which I believe these changes could fix)
I think there's still an issue, although it takes a somewhat different form. Weasel doesn't do its own analysis anymore but I still get missing var warnings in that example project if I run
|
I suspect these errors are related to #48 |
autogenerated with https://github.com/MalloZup/doghub: issue inactive since 450 days. Please update the issue or close it |
When I piggyback into the Weasel REPL, many "false-positive" code analysis warnings are emitted. These are mostly of the form "Referred var some.namespace/var-name does not exist," but other similar warnings are emitted. Nothing breaks for me, and the REPL functions.
This occurs when
(cljs.repl/analyze-source (:src this))
is called from withinweasel.repl.websocket/websocket-setup-env
.I've traced the root cause down to an inability of the ClojureScript compiler to locate the source of dependent namespaces to analyze. To fix this appears to require two changes:
:root
in the ClojureScript compiler environment needs to be set to the source root. This root needs to follow the JVM classpath convention. In other words it needs to be precisely at the level containing the namespace directories. Using the weasel project structure itself as an example, this would besrc/cljs/
.:source-paths
perlein-cljsbuild
) a separate analysis needs to be done for each distinct root. Thus, Weasel would need to accomodate a:src-paths
option in lieu of its current:src
option.With a
:src-paths
option, if I replace(cljs.repl/analyze-source (:src this))
with the following formthen piggybacking into Weasel works without any "false-positive" warnings, and if you inspect the ClojureScript compiler's behavior, you can see that it succeeds in loading dependent namespaces and analyzing them.
The text was updated successfully, but these errors were encountered: