Clojurians Log v2

dbg wrong-pre-post: condition=(do (println "job-xml:" %) true) line=152 test-ast :op=:do 

{:post [(do (println "job-xml:" %) true)]}

looks like this code that is doing it https://github.com/jonase/eastwood/blob/672ed22b8e3595862b735350862c8cd04843afd9/src/eastwood/linters/typos.clj#L1034

I think the real fix here is to not use a :post condition as a debug printf :P

(fixing my codebase that is)

And also hinting that this should be a proper warning in eastwood 😉

https://github.com/jonase/eastwood/issues/283

yeah - I didn't go too deep reading that, but it seems like it would have been a constant-check type error if eastwood had analyzed more deeply

@slipset thanks btw

is there a known corner case for a destructure of constant data in order to name keys of a hard-coded map resulting in constant test warnings?

Not sure, @andy.fingerhut might know?

Often when writing linters I do not know all of the cases that the tools.analyzer.jvm analyzed data structures might contain, and rather than try to be exhaustive, I iteratively create test Clojure programs that I think should cause the warning, print out what kind of map tools.analyzer created in that part of the code, and handle it. If I think I get several cases covered, I try it out on the crucible set of Clojure projects and look for more. The print statement quickly alerts me if it encounters a case that Eastwood doesn't cover.

It is not a useful Eastwood warning, true, and it is a bit of a wart.

Perhaps changing it to a proper Eastwood warning with a type like :eastwood-unimplemented-case might be better?

The docs could explain that such warnings would be great to report as an Eastwood issue (especially if there is a shareable reproducing test case, as usual) so that Eastwood might be enhanced to handle that case better.

oooh - I wonder how I did this

ArityException Wrong number of args (2) passed to: error-messages/format-exception
	eastwood.lint/report-analyzer-exception (lint.clj:373)
	eastwood.lint/report-analyzer-exception (lint.clj:369)
	eastwood.lint/lint-ns (lint.clj:408)
	eastwood.lint/lint-ns (lint.clj:399)
	eastwood.lint/eastwood-core/fn--7673 (lint.clj:838)
	eastwood.lint/eastwood-core (lint.clj:836)
	eastwood.lint/eastwood-core (lint.clj:763)
	eastwood.lint/eastwood (lint.clj:965)
	eastwood.lint/eastwood (lint.clj:946)
	eastwood.lint/eastwood-from-cmdline (lint.clj:978)
	eastwood.lint/eastwood-from-cmdline (lint.clj:977)
	clojure.lang.Var.invoke (Var.java:381)
	eastwood.versioncheck/run-eastwood (versioncheck.clj:15)
	eastwood.versioncheck/run-eastwood (versioncheck.clj:9)
	user/eval164 (3e4db74ec9058b02f12b9083b40770ed2b91c24e-init.clj:1)
	user/eval164 (3e4db74ec9058b02f12b9083b40770ed2b91c24e-init.clj:1)
	clojure.lang.Compiler.eval (Compiler.java:7062)
	clojure.lang.Compiler.eval (Compiler.java:7052)
	clojure.lang.Compiler.load (Compiler.java:7514)
	clojure.lang.Compiler.loadFile (Compiler.java:7452)
	clojure.main/load-script (main.clj:278)
	clojure.main/init-opt (main.clj:280)
	clojure.main/init-opt (main.clj:280)
	clojure.main/initialize (main.clj:311)
	clojure.main/null-opt (main.clj:345)
	clojure.main/null-opt (main.clj:342)
	clojure.main/main (main.clj:424)
	clojure.main/main (main.clj:387)
	clojure.lang.Var.applyTo (Var.java:702)
	clojure.main.main (main.java:37)

I think that might be a known issue that has a fix in latest master version of Eastwood

https://github.com/jonase/eastwood/issues/274

yeah - I was just looking and didn't find it in master, I'll double check my version

I think there was an attempted release of Eastwood version 0.2.9, but due to some kind of naming/release issue 0.2.9 is actually identical to 0.2.8, or something weird like that?

I asked for 0.2.9 and it printed 0.2.8 on startup - I figured it was a project.clj config issue and I triaged it lower than making the linter accept my project code haha

(it's a big old project and introducing a linter has been an adventure)

Are you getting that error when you ask for 0.2.9 ?

yes

(or - I was, I just deleted some commented code and the error went away)

originally I had a false positive constant test warning because a literal hash map was destructured in a let block

then I commented that out and used keyword lookup on each key separately, then got that stack trace

then deleted the commented code and the stack trace went away

I could try releasing an Eastwood 0.2.10 with latest master code, one that prints 0.2.10 as the version number in the output, and see if it fixes anything.

cool - not a priority for me as I found something that works, but that sounds useful generally

also - figuring out how to avoid a false positive constant test for destructuring a map literal would be nice - some day

Might be better if @slipset did it, since they have made changes to Eastwood version stuff that I might not do correctly.

OK, looking at commit history carefully now, the fix for that exception was committed after the repository was tagged with "eastwood-0.2.9", so the fix might not be in any released version now, if that tag matches the released source with version 0.2.9

Sorry if I'm rambling here -- I haven't been doing development on Eastwood for the last few releases, so a bit out of the loop (which is normal when one asks someone else to step in to continue development -- I'm not complaining :)