ChunkMatches: drop trailing newline #709
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Fuzz test failed on commit dfff4eb. To troubleshoot locally, use the GitHub CLI to download the seed corpus with |
|
Fuzz test failed on commit d12ed33. To troubleshoot locally, use the GitHub CLI to download the seed corpus with |
|
Fuzz test failed on commit c840017. To troubleshoot locally, use the GitHub CLI to download the seed corpus with |
camdencheek
force-pushed
the
cc/drop-trailing-newline
branch
from
c840017 to
6ac8e22
Compare
camdencheek
commented
Dec 8, 2023
Comment on lines
+26
to
+34
| # Pinned a commit to make go version configurable. | ||
| # This should be safe to upgrade once this commit is in a released version: | ||
| # https://github.com/jidicula/go-fuzz-action/commit/23cc553941669144159507e2cccdbb4afc5b3076 | ||
| - uses: jidicula/go-fuzz-action@0206b61afc603b665297621fa5e691b1447a5e57 | ||
| with: | ||
| packages: 'github.com/sourcegraph/zoekt' # This is the package where the Protobuf round trip tests are defined | ||
| fuzz-time: 30s | ||
| fuzz-minimize-time: 1m | ||
| go-version: '1.21' |
There was a problem hiding this comment.
Needed to update this so the build doesn't fail when using new go 1.21 features.
camdencheek
commented
Dec 8, 2023
Comment on lines
+35
to
+36
| // Trim the last newline before splitting because a trailing newline does not constitute a new line | ||
| lines := bytes.Split(bytes.TrimSuffix(content, []byte{'\n'}), []byte{'\n'}) |
There was a problem hiding this comment.
e.g. one\ntwo\nthree\n is three lines, not four. Same as one\ntwo\nthree
keegancsmith
approved these changes
Dec 11, 2023
Co-authored-by: Keegan Carruthers-Smith <[email protected]>
camdencheek
added a commit
that referenced
this pull request
Apr 18, 2024
The updates our "line model" to fix the edge cases that led to sourcegraph/sourcegraph#60605. In short, this changes the definition of a "line" to include its terminating newline (if it exists). Before this, we had defined a "line" as starting at the byte after a newline (or the beginning of a file) and ending at the byte before a newline (or the end of the file). The problem with that definition is that a newline that is the last byte in the file can never successfully be matched because we would trim that from the returned content, so any ranges that would match that trailing newline would be out of bounds in the result returned to the client. That's the reason behind the panics caused by #709, which was an attempt to formalize the "line does not include a trailing newline" definition. So, instead, this redefines a line as ending at the byte after a newline (or the end of the file). This means that a regex can successfully and safely match a terminating newline.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'd like to start taking advantage of the
NumContextLinesoption, but have been running into an issue where, if context lines were to extend past the end of the file, we get the trailing newline at the end of the file.This is not desirable because the empty slice after a trailing newline is not treated as a "line" by any editor, so when we split on newlines, an empty line is shown to the user. By the time we're splitting on newlines, we do not know whether or not we're at the end of the file, so we cannot know whether we can trim that trailing newline, or whether it is, correctly, an empty line that should be rendered.
This is really annoying stuff that bites us elsewhere as well (searcher, syntax highlighter). It might be nice to unify the definitions of "what is a line" in some library, but for now, I'll be happy with "don't return an extra line."