Found while verifying #235's follow-up (parallelising the format check): I diffed two runs of the SAME binary over the SAME tree and they disagreed.
117a118
> info internal/codeindex/query.go:28 Error return value of `f.Close` is not checked (errcheck) (lint)
119,121c120
< info internal/codeindex/query.go:478 ...
< info internal/debt/debt.go:68 ...
Both runs are the unmodified binary on an unmodified tree. The findings are advisory info lines from the lint domain, and the set is capped — so which subset survives the cap changes between runs, not just the order within it.
Why it matters
- "Did my change alter the report?" is unanswerable when the report varies on its own.
- It cost real time here: comparing a refactor's output against the original showed four differing lines that looked like a regression and were not. The only way to establish that was to run the old binary twice.
- Everything else in procoder's output is deterministic, which is what makes this surprising rather than expected.
Likely cause: findings collected from a concurrent or map-ordered source and truncated before sorting. A stable sort on (file, line, rule) before the cap would fix both the order and which findings the cap keeps.
Not blocking — these are info lines and the verdict is unaffected.
Found while verifying #235's follow-up (parallelising the format check): I diffed two runs of the SAME binary over the SAME tree and they disagreed.
Both runs are the unmodified binary on an unmodified tree. The findings are advisory
infolines from the lint domain, and the set is capped — so which subset survives the cap changes between runs, not just the order within it.Why it matters
Likely cause: findings collected from a concurrent or map-ordered source and truncated before sorting. A stable sort on (file, line, rule) before the cap would fix both the order and which findings the cap keeps.
Not blocking — these are
infolines and the verdict is unaffected.