Open andrewzhurov opened 2 years ago
Does the debugger work for you with a variety of other defns in other projects?
Does the debugger work for you with a variety of other defns in other projects?
Yes, works as expected (regarding the subject behavior) with most of the defns I've used it with. I have stumbled only on 2 defns, I think, in clj-kondo that caused that (may be that one of them used another internally).
Thanks! I now see in your updated issue that it boils down to a Method code too large!
IME hacking on various tools e.g. Eastwood and Cloverage, Method code too large!
are often just part of life for dynamic tooling.
https://github.com/clj-kondo/clj-kondo/blob/9195cc0f0761a2b673816f5296a95380917ff05b/src/clj_kondo/impl/linters.clj#L202 is certainly one beast of a function. I also recall that clojure.core/doseq
has a 'naive' implementation in terms of emitted bytecode, with no plans to change it.
99% of times, the defns that trigger these issues can be decomposed into smaller ones. I think everyone benefits from that, i.e. human readers too.
A fix might not be impossible (it wasn't for Eastwood) but this is the sort of edge case that is often not worth the effort. Of course, PRs welcome.
Cheers - V
...As a quick note, perhaps a ->>
chain with filter
, map
, etc might be equivalent to that for
but without the bytecode size bloat.
I do avoid for
/doseq
mainly for other reasons (often the aforementioned chains are neater, and translatable to transducers), but this one might be yet another reason for making for
-avoidance a good habit to follow in your own codebases.
On my experience seeing debugger fail on the most juiciest pieces I would benefit having it the most was a major downer. And seeing misleading error messages added frustration to it. It worries me that it's not a rare occasion.
I expect from a debugger the exact opposite - it's a solid tool that gets me through tough times.
Having need to refactor code in order to be able to use debugger sounds not ideal, as:
All and all, I'd really hope for debugger to be robust.
I went through my code comments of where debugger resulted in an error - errors differ, but perhaps the root cause is the same.
https://github.com/clj-kondo/clj-kondo/blob/9195cc0f0761a2b673816f5296a95380917ff05b/test/clj_kondo/analysis_test.clj#L1557 (novel error)
Caused by java.lang.RuntimeException
Unable to resolve symbol: deftest in this context
Same error is given by: https://github.com/clj-kondo/clj-kondo/blob/9195cc0f0761a2b673816f5296a95380917ff05b/test/clj_kondo/analysis_test.clj#L1619 https://github.com/clj-kondo/clj-kondo/blob/9195cc0f0761a2b673816f5296a95380917ff05b/test/clj_kondo/analysis_test.clj#L1507
https://github.com/clj-kondo/clj-kondo/blob/9195cc0f0761a2b673816f5296a95380917ff05b/src/clj_kondo/impl/linters.clj#L594 (same error as in the issue)
1. Unhandled java.lang.IllegalArgumentException
No implementation of method: :send of protocol:
#'nrepl.transport/Transport found for class: nil
[...] All and all, I'd really hope for debugger to be robust.
That's a fair hope, I'm just informing you that technically is not easy / not a new issue at all (from what can be found in comparable projects) and that the chances of someone spontaneously fixing this are pretty low.
I agree that No implementation of method: :send of protocol:
is misleading and might be low-hanging fruit to get fixed.
Please note
As I've been filling this issue I have narrowed down the cause of the exception. I'll provide the narrowed down version and the real-world version.
Narrowed-down version seems to have the root cause exception. Real-world version seems to have an exception of not the root cause.
Narrowed-down expected behavior
In Emacs,
cider-debug-defun-at-point
on the following defn results in defn marked as being debugged.Narrowed-down actual behavior
Results in "Method code too large!" exception shown in
*cider-error*
buffer. (whereas havinga98 a
binding removed results in no-error behavior)*cider-error*
buffer content:Narrowed-down steps to reproduce
Create a local file with the code. Launch an nrepl:
Open Emacs and connect to the nrepl. E.g., via
cider-connect-clj
. In my case, cider informs of such environment:Navigate to the defn.
Put cursor at the defn symbol,
cider-debug-defun-at-point
.*cider-error*
is expected to pop up.Real-world expected behavior
In Emacs
cider-debug-defun-at-point
on this defn results in defn marked as being debugged.Real-world actual behavior
Results in
*cider-error*
buffer with:Real-world steps to reproduce the problem
Have the same defn locally. E.g., by having clj-kondo repo locally and checkouting to the exact commit (latest atm):
Launch cider-nrepl 0.28.3 (latest atm):
Open Emacs and connect to the nrepl. E.g., via
cider-connect-clj
. In my case, cider informs of such environment:Navigate to the defn. E.g., via
project-find-regexp RET defn lint-var-usage
. E.g., viafind-file
atclj-kondo/src/clj_kondo/impl/linters.clj
, line 202.Put cursor at the defn symbol,
cider-debug-defun-at-point
.*cider-error*
is expected to pop up.Environment & Version information
cider-nrepl version
0.28.3
cider version
1.3.0 (Ukraine)
nrepl version
0.9.0
Clojure version
1.9.0
Java version
1.8.0_161
Operating system
Guix, linux kernel. Based on this config with some tweaks.