You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Diff line numbers are zero-indexed, don't account for frontmatter #797
While using cargo-semver-checks, I noticed a discrepancy between the line numbers reported in diffs between ".snap" test results. Apparently, these numbers are being calculated by insta. Here is what it looks like:
This says that the line which changed was line 3. However, this ignores both the fact that file line numbers aren't usually zero-indexed, and also the frontmatter in the file. Here is the top of the file in my editor:
I wanted to start a discussion about this. Is there a straightforward way to align the test output line numbers with the actual files on disk? If the frontmatter can't be included in the diff, perhaps the change could be as simple as replacing frontmatter with the equivalent number of blank lines before passing files to the diff tool? (There's also the zero-index issue too, though.)
Thanks for the quick reply! On the second issue, I'd be happy to submit a PR. It would be helpful to have a pointer to a good file/function to start looking in. I'm not at all familiar with insta at this point.
And on the first one… is the output being used as expected in cargo-semver-checks? It always takes a moment for me to do the math and figure out where exactly I'm supposed to be looking in the file to find the referenced change. I'm a bit surprised that it's expected behavior for the file referenced by the path to not match the new version in the diff output, but my only experience is with c-s-c. Might it be possible to pass a line number offset, which could be zero in the common case, but might be the length of the frontmatter if the API user wanted it?
Update: I should say: if the key thing is avoiding the diff including changes made to the frontmatter itself, that makes perfect sense. However, I would hope we could find a solution which doesn't misinform users who go to find the differences in the file which the snapshot diff is pointing at. But please do let me know if I'm missing something here.
(for completeness: I don't have much for you on providing a line number in the snapshot file. the line number refers to the diff in the output. maybe there's something like an emacs extension that would be helpful...)
Activity
max-sixty commentedon Sep 1, 2025
they are indeed the line numbers in the output, not in the snapshot file; that's intentional.
I agree on the 0 vs 1 issue though; happy to take a PR for that change (not impossible there's something I'm missing though)
nk9 commentedon Sep 1, 2025
Thanks for the quick reply! On the second issue, I'd be happy to submit a PR. It would be helpful to have a pointer to a good file/function to start looking in. I'm not at all familiar with
instaat this point.And on the first one… is the output being used as expected in
cargo-semver-checks? It always takes a moment for me to do the math and figure out where exactly I'm supposed to be looking in the file to find the referenced change. I'm a bit surprised that it's expected behavior for the file referenced by the path to not match the new version in the diff output, but my only experience is withc-s-c. Might it be possible to pass a line number offset, which could be zero in the common case, but might be the length of the frontmatter if the API user wanted it?Update: I should say: if the key thing is avoiding the diff including changes made to the frontmatter itself, that makes perfect sense. However, I would hope we could find a solution which doesn't misinform users who go to find the differences in the file which the snapshot diff is pointing at. But please do let me know if I'm missing something here.
max-sixty commentedon Sep 3, 2025
closed by #799
(for completeness: I don't have much for you on providing a line number in the snapshot file. the line number refers to the diff in the output. maybe there's something like an emacs extension that would be helpful...)