Re: [PATCH v4 08/19] worktree: fix a trivial leak in prune_worktrees()

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

I'd rather see your reroll with the above addition of UNLEAK() than
without it, to fix the breakage.

I don't mind that UNLEAK() being in-tree until a better fix for that
leak, but doesn't the v5 I sent also address this?

The issue was that I mis-marked a test as passing, when it only passed
depending on my local compiler (-fsanitize=leak is fickle
sometimes). Now that we're not marking that test as leak-free there's no
need for the UNLEAK() for now, no?

Or is there some edge case I didn't spot/notice?

The top-level singleton instance of "filter" that is used once and
never grows unbounded is a perfect use case for UNLEAK().  And with
it, the test DOES get leak-free, so it would be appropriate to keep
the PASSES variable added to the script (until it gets broken
again).

Or did you have any other uses of tools with leaks in the script,
other than the one that is fixed with the UNLEAK()?