Avoid oscillating line wrapping due to symbol indices - #162608
Conversation
A comment against PR 151817 mentioned that the test file added in this PR kept causing "arbitrary" test file changes. This is because one line of the expanded output sits *just* at 78 columns, which is the pretty-printer's margin. Adding or removing a symbol shifts every index after it, and when one of those gains or loses a digit, the wrapping moves. We cannot use `normalize-stdout` as the layout is decided before normalization runs. We fix this by avoiding a strict golden comparison, and instead using a regex to directly test that the expected syntax contexts exist in the expanded output.
|
r? @TaKO8Ki rustbot has assigned @TaKO8Ki. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
Thanks! An alternative may be to normalize the newlines as well. I don't know if that is practical. |
I think you'd end-up needing to flatten the whole file, which would the make the golden comparison "a bit rough". I am not attached to what I've done in this PR at all though, if there's another approach people prefer. |
|
☔ The latest upstream changes (presumably #162631) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
A comment against PR 151817 mentioned that the test file added in this PR kept causing "arbitrary" test file changes.
This is because one line of the expanded output sits just at 78 columns, which is the pretty-printer's margin. Adding or removing a symbol shifts every index after it, and when one of those gains or loses a digit, the wrapping moves.
We cannot use
normalize-stdoutas the layout is decided before normalization runs.We fix this by avoiding a strict golden comparison, and instead using a regex to directly test that the expected syntax contexts exist in the expanded output.
LLM disclosure: I used an LLM to help me understand the problem and how the regex would look, which the LLM then actioned. I reviewed the diff and the commit (along with the message) was performed by hand with me (with the LLM checking the content of the commit message, but the commit message was, indeed, written by a human).