Closed jellelicht closed 2 years ago
Thanks!
Issue transfered to cider-nrepl which does the macroexpanding.
Might give this a shot soon enough.
I failed to reproduce the issue with this commit https://github.com/clojure-emacs/cider-nrepl/commit/1dfeef8535542e1a1c880555b8fcd699c77ffe8f so probably I will be out of ideas.
If you have the spare time, maybe you can try the same over a couple other JDKs; 12
is bit of an odd one. The LTS JDKs are 8, 11 and 17.
8
is the less likely one to give odd errors (such as the one you shared: Unhandled java.lang.ClassCastException class clojure.lang.Var$Unbound cannot be cast to class clojure.lang.DynamicClassLoader (clojure.lang.Var$Unbound and clojure.lang.DynamicClassLoader are in unnamed module of loader 'app')
)
There's also a low but real chance that setting :jvm-opts ["-Dorchard.use-dynapath=false"] in deps.edn
per https://github.com/clojure-emacs/orchard/tree/fa5bbb670bd502e59dfa61cfa8e65def38897239#configuration-options would leave the classloaders cleaner (unaltered), making the issue less likely.
@vemv thanks, I will be trying out your suggestions, and report back here. Were you able to at least reproduce the issue as I did (via cider)?
I can reproduce my issue using the linked repo with the following java versions, both with and without the use-dynapath settings.
I’ve not yet been able to test 17, as that has not been packaged for my distro yet. @vemv can I bother you to try to my reproducer in the repo I linked in my original issue?
I had one other person on the cider discord confirm my issue, but it would be nice if you can verify that you don’t see the issue at all (classic case of PEBKAC then on my end 😉).
I don't run a modern cider.el myself.
One thing you can try is renaming user.clj to something else - user
has a special semantic and is loaded automatically / early.
I made sure to try with something that is not user.clj
as well; same results. Would you be so kind as to move this back to the cider project in that case? TBH, I don’t really think the problem is here; since the macro-expanding the exact same code works when used in a lein project /w the same versions of pretty much everything else. Thanks for your help here either way!
EDIT: Since this issue only seems to occur for deps.edn projects, and not lein projects, I doubt we’ll be able to find + fix the problem here either way.
Would you be so kind as to move this back to the cider project in that case?
It's in bit of a grey zone, as we don't really know what's going on. We can default to avoid churn, I'm not sure you'd get any more help over the cider.el tracker.
n.b. as reported, so far this seems a rather low-impact corner case (which I'm willing to work through regardless).
One thing that would help is comparing the java
processes. Try ps aux | grep java
and please paste here the java
processes that are ultimately running your code (e.g. the final JVM spawned by Lein, and the one JVM spawned by tools.deps).
It also would help to hit the macroexpand ns directly from a repl. This way we bypass a good chunk of the cider.el / nrepl machinery and can discard at least one hypothesis.
Cheers - V
btw an awesome repro might look like this:
clojure --eval "(require 'cider.nrepl.middleware.macroexpand), (cider.nrepl.middleware.macroexpand/,,, ,,,)"
Everything works as one would expect when directly calling into cider.nrepl.middleware.macroexpand, but I found a more fundamental issue (which might already give you some ideas on what the actual cause of the problem might be):
Given the following macro:
(defmacro dummy []
(println (deref clojure.lang.Compiler/LOADER))
42)
And a deps.edn-based cider-repl will (correctly) M-x cider-macroexpand-all
a call to (dummy)
to 42. Kicker is, that the printen output will be:
#object[clojure.lang.Var$Unbound 0x3daadf30 Unbound: #<Var: --unnamed-->]
If one were to actually run (dummy) on the repl, one would see:
#object[clojure.lang.DynamicClassLoader 0x335cbf1b clojure.lang.DynamicClassLoader@335cbf1b]
42
In a lein-based cider-repl, both will display a clojure.lang.DynamicCLassLoader! @vemv Does this help in any way?
Yes, sure! That's much useful.
I reckon that cider.nrepl.middleware.macroexpand
could bind LOADER
to a new DynamicClassLoader instance if it's currently unbound.
n.b., being unbound is its default state, so there's possibly more than one reason why it might remain unbound when invoking cider.nrepl.middleware.macroexpand
. Which is a good thing here: we'd fix this issue, and possibly other unforeseen code paths.
Does this sound good to you?
(thanks for the 👍; I repro'd + fixed this in the meantime. PR soon)
Please Let me know if there’s something I can do to help test
@vemv I can confirm that it fixes my use-case! Thanks again!
object[clojure.lang.Var$Unbound 0x3daadf30 Unbound: #<Var: --unnamed-->]
This is misleading, this means the Var has no root binding, but it does usually have a thread-local binding during eval:
In a plain clj REPL:
user> [clojure.lang.Compiler/LOADER @clojure.lang.Compiler/LOADER]
;;=>
[#<Var: --unnamed--> #object[clojure.lang.DynamicClassLoader 0x7726e185 "clojure.lang.DynamicClassLoader@7726e185"]]
Got it, very interesting thanks!
Still, the open PR seems to make sense since its accompanying test would fail without the fix itself.
It can make sense if we consider during eval
to not include the macroexpand phase?
i.e. the cider-macroexpand-all macroexpands, does not eval and therefore LOADER
is truly unbound.
Released in CIDER 1.2 / cider-nrepl 0.27.4.
Expected behavior
Being able to macro expand forms that happen to define interfaces, in either deps.edn or leiningen projects
Actual behavior
A crash pop-up when macro expanding forms that happen to define interfaces, but only in deps.edn projects.
Steps to reproduce the problem
I made a tiny example that seems to be reproducible for at least one other person: https://github.com/jellelicht/cider-macro-repro
Steps to reproduce the problem (alt)
(macroexpand-1 '(definterface IFoo))
with cider-nrepl's machineryEnvironment & Version information
CIDER version information
Emacs version
27.2
Operating system
GNU Guix (current master)
Stacktrace