vemv

As a thing that maybe can help, this wall of flags helps me avoid all sort of OOMs (most specifically, for stack-heavy workloads): ```clj [;; Prevents a specific type of...

Yes the https://github.com/clojure-emacs/refactor-nrepl/issues/245#issuecomment-567265738 repro hints so

FWIW, https://github.com/gfredericks/how-to-ns has a fairly fine-grained support for reader conditionals Starting with 3.0.0, refactor-nrepl will be closer to 'how-to-ns' style so mixing and matching different tooling wouldn't even be particularly...

Although popular, `(set! *warn-on-reflection*)` is not guaranteed to work. No top-level `(set! ... )` is - personally I keep seeing projects tripping up on this nuance. Furthermore `(set! *warn-on-reflection*)`, while...

I've (unsuccessfully) tried to reproduce the issue here https://github.com/clojure-emacs/refactor-nrepl/pull/325 Feel free to hack it, you might be able to break the build with a sophisticated-enough example :)

I'll see if I can add a temporary binding for `*warn-on-reflection*`.

Cheers yes there's similar tech in eastwood https://github.com/jonase/eastwood/blob/8a6655f592004a7d6e028380144cb1210bb7a9f5/src/eastwood/analyze_ns.clj#L422-L435 Although it's not as easy as a `binding`: given that tools.analyzer is used, any analyzed form itself could be performing a `set!`....

Isn't it another namespace the one at fault? `diagnostic_report_repository.clj`

A `Syntax error compiling [...]` is generally always followed by a `caused by:` and then the cause of the exception, please make sure to retrieve the whole stacktrace

I wasn't able to reproduce this. I'll add a test case to `refactor-nrepl.analyzer-test` with that defprotocol (which is worth testing because it shadows `update`). Do feel free to reopen the...