On Fri, Aug 26 2022, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > >>> But the fix here isn't to delete unused.cocci, but to hold off on the >>> UNUSEwork D() patches until we figure out how to make coccinelle jive with >>> them. >> >> Yeah, my general skepticism and disappointment above notwithstanding, >> this seems like the best path forward from here. I tried a few other >> tricks (like --macro-file and --iso-file), but if its parser chokes, I >> don't think there's much we can do about it. Even if we wrote a patch to >> coccinelle itself (and I have no interest in doing that myself), it >> would take a while to become available. > > If it is just a single unused.cocci, I would actually think removing > it would be a much better path forward. UNUSED() that renames to > help folks without checking compilers would help noticing bad code > much earlier than unused.cocci many contributors are not running > themselves anyway. I think Jeff King's reply covers what I would have said, except one thing I'd like to add: My reading of this is that you're misimpression that unused.cocci and Jeff's UNUSED macro are two ways to the same end-goal, and that if we keep the macro we could lose the coccinelle rule. But they're doing completely orthogonal checks, the unused.cocci is finding code that's *actually used* accordingn to the compiler, but which we know results in code that's functionally unused. E.g. doing nothing with a "struct strbuf" except to initialize it, and call strbuf_release() on it. Whereas the UNUSED macro is finding parameters that are truly unused, and which we could have expected compilers to optimize out already. It's just helping us maintain our own code hygene. I suspect that we'll also find "functionally unused" code with the UNUSED macro, but only indirectly. I.e. we might find that all users of an interface don't need the Nth parameter, and so we don't need to prepare it for them.
