eastwood

dgr 2024-09-18T19:16:44.315919Z

I have a test that is using the wrong function arity. I’ve figured out how to disable the :wrong-arity linter for the specific namespace in which the “error” occurs, but that seems overly broad. Is there a way to scope the :ignored-faults to a specific function or even something like clj-kondo’s #_{:clj-kondo/ignore [:invalid-arity]} to ignore a linter on just the following form? I found the syntax for ignoring a linter for a specific line and column within a namespace, but that seems overly brittle when lines and columns may shift as tests are added and edited. I’d like some sort of annotation that is as tightly specific as possible without being brittle, but I can’t seem to find anything like that in the Eastwood docs. Thanks.

vemv 2024-09-18T19:19:01.000049Z

👋 The first question to ask is why the bug happening in the first place :) May it be fixed by placing :arglists metadata? It's a idiomatic thing to do, even outside of Eastwood

dgr 2024-09-18T19:24:52.218069Z

Again, it’s test code, so it’s a deliberate bug, basically to hold a place in a list of tests where I have zero arguments (bug, throws), one argument, two arguments, and three arguments. I’m not sure what “placing :arglists metadata” means. Can you point me at an example of that and how it helps? I read the clojure.java.jdbc/query example under the :wrong-arity section of the README and I’ll admit that I didn’t really understand it.

vemv 2024-09-18T19:45:45.315679Z

Oh if it's a deliberate bug it's a different story, :arglists doesn't apply there Frankly, is that a really necessary test case? You have up to two linters (kondo, Eastwood) checking for no incorrect calls within your codebase. And then you have Clojure's own exception handling for wrong arities In principle, any function from anywhere can be incorrectly called, the way Clojure developers defend against those is 1) linting, 2) implicitly through other unit/integration testing, i.e. if a through test passes, it's impossible that there are arity exceptions for that section of the code.

vemv 2024-09-18T19:46:39.748599Z

Of course, I may be missing some context. But for this use case I wouldn't extend Eastwood capabilities

vemv 2024-09-18T19:47:24.631949Z

Quick alternative - extract the deftest to a ns named foo_arity_test.clj and place the coarse-grained rule there

dgr 2024-09-18T19:47:52.003359Z

No, it’s not completely necessary. I can just comment it out and say “This works but the linter barfs” and be done with it. I was just hoping that there was a way to narrowly target an exception in Eastwood that didn’t involve line numbers.

vemv 2024-09-18T19:48:41.297309Z

You can target the namespace, and if the namespace name suggests it's delimited to a tiny concern, then you won't unintentionally exclude other stuff

dgr 2024-09-18T19:50:07.420119Z

In this case, I don’t think it’s worth a bunch of workarounds and hoop jumping. If Eastwood doesn’t have an easy way to scope down an exception to a function or form, that’s fine. I’ll just comment it out and leave the comment as the placeholder.

👍 1
dgr 2024-09-18T19:52:14.082539Z

Thanks for your help, @vemv. Always appreciated.

🍻 1
vemv 2024-09-18T19:51:05.711309Z

ℹ️ Unrelated note, I don't have much time to work on OSS or Eastwood these days, so a Clojure 1.12 compat thing won't happen unless someone makes it! (I don't know if tools.analyzer caught up with the syntax changes?)