Closed rlbdv closed 3 years ago
Hi!
Could you explain better the problem being experienced?
From your example, specifying both the line and a would-be "function" would look redundant to me.
A :line already mutes any (reflection) warning for that specific ns and line.
Ahh, sorry, I was suggesting function names as an additional option, so the example above would indicate two suppressions, one for some-function
, and one for whatever was on line 79. That way, in cases where you know that you want to ignore all warnings of a particular kind for a particular function, you can say that in a way that's insensitive to line number changes.
It's a tradeoff, of course, with respect to precision vs busy-work, but in cases where a reflection (for example) can be isolated to a trivial helper function, it seemed like it might be plausible.
I'm not excessively interested in complicating the :ignored-faults "DSL", right now its implementation is conveniently thin. I don't want to make ignoring issues easy anyway - often they hide an actual underlying problem, be it in one's app or in Eastwood itself.
One thing that I have in the radar though is making Eastwood fail if a given :ignored-fault had no effect whatsoever. It's Rubocop's behavior from what I talked with @bbatsov once.
I have a workaround (just move the functions to a separate module), but it might be convenient to allow functions to be added to the
:ignore-faults
value, e.g.:Thanks