Cider-macroexpand-all in deps.edn project of definterface crashes #721
Comments
|
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 1dfeef8 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;
|
|
There's also a low but real chance that setting |
|
@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 - |
|
I made sure to try with something that is not 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. |
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 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: And a deps.edn-based cider-repl will (correctly)
If one were to actually run (dummy) on the repl, one would see: In a lein-based cider-repl, both will display a clojure.lang.DynamicCLassLoader! |
|
Yes, sure! That's much useful. I reckon that n.b., being unbound is its default state, so there's possibly more than one reason why it might remain unbound when invoking 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! |
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: |
|
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 i.e. the cider-macroexpand-all macroexpands, does not eval and therefore |
|
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
The text was updated successfully, but these errors were encountered: