Fix baseline duplicate replacements - #6872
Conversation
Generated by 🚫 Danger |
|
Author of #6871. The anchor approach is the right call: an unchanged duplicate is the evidence that the group did not shift, which is exactly the distinction the old fallback could not make. Keeping the shift-tolerant path where no exact match survives leaves the intentional behaviour intact. One residual worth stating, not a request to change anything. When every duplicate in a group is replaced in the same run, no anchor survives, the group falls through to the shift-tolerant path, and the swap stays invisible. That is narrower than what #6871 reported — it needs the whole group to turn over at once — but it is the same shape, and it is better known now than discovered later. Reason and line text remain the only keys on that path, so the residual is bounded by how generic those are. Checks are green apart from the ones waiting on maintainer approval. |
4 participants
Fixes #6871
Summary
Root cause
After exact matches are removed, the fallback comparison used only the number of remaining violations with the same text and reason. A replacement could therefore be hidden by an unmatched baseline duplicate with the same key.
An unchanged duplicate now acts as an anchor: if the remaining counts are equal within that group, the unmatched current violations are reported. A group with no exact match still follows the existing shift-tolerant behavior.
Tests
swift test --filter BaselineTests