Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix LSP leading comment formatting #3424

Merged
merged 2 commits into from
Oct 29, 2024
Merged

Conversation

stefanvanburen
Copy link
Member

Fixes #3423.

Copy link
Contributor

github-actions bot commented Oct 28, 2024

The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed✅ passed✅ passed✅ passedOct 29, 2024, 4:59 PM

Copy link
Member

@mcy mcy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for catching this. I think have a minor quibble about how this is resolved, though. Please see my comment.

Comment on lines 221 to 233
Range: protocol.Range{
// The formatter always returns the entire file; make sure we
// represent the edit as the entire range (which may not match up to
// the file's NodeInfo.Start()).
Start: protocol.Position{
Line: 0,
Character: 0,
},
End: protocol.Position{
Line: uint32(nodeInfo.End().Line) - 1,
Character: uint32(nodeInfo.End().Col) - 1,
},
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still potentially incorrect, due to trailing comments.

Instead, given that parsing is a relatively intense operation, I would prefer that we simply count the number of
lines in file.fileNode and the number of characters on the last line, and construct a Range using that. Don't bother with the spans in the AST, since they clearly don't reflect what we actually mean.

Also, include the following comment:

// XXX: The current compiler does not expose a span for the full file. Instead of
// potentially undershooting the correct span (which can cause comments at the
// start and end of the file to be duplicated), we instead manually count up the
// number of lines in the file. This is comparatively cheap, compared to sending the
// entire file over a domain socket.

Also, please file a bug against protocompile to include a way to retrieve a span of the whole file.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, it doesn't seem like the issue extends to trailing comments, maybe because NodeInfo.End() has special handling for EOF?

I would prefer that we simply count the number of lines in file.fileNode and the number of characters on the last line, and construct a Range using that.

I was looking around at the FileNode APIs and didn't find much exposed that would help with that; mind pointing me to how that would be done / make that change yourself? (Happy for you to take this over; my protocompile knowledge is weak 😅.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm juggling a bunch of PRs already and am about to go on vacation, so I prefer you do it if only to make sure it gets done. Also, good excuse to grow your knowledge!

Anyways, the right way to do this:

var lastLine, lastLineStart int
for i := 0; i < len(file.text); i++ {
  // NOTE: we are iterating over bytes, not runes.
  if file.text[i] == '\n' {
    lastLine++
    lastLineStart = i + 1 // Skip the \n.
  }
}
lastChar := len(file.text[lastLineStart:]) - 1 // Bytes, not runes!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0057f0d, PTAL!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, please file a bug against protocompile to include a way to retrieve a span of the whole file.

bufbuild/protocompile#360!

@stefanvanburen stefanvanburen requested a review from mcy October 29, 2024 16:59
@stefanvanburen stefanvanburen merged commit b5f41e3 into main Oct 29, 2024
10 checks passed
@stefanvanburen stefanvanburen deleted the svanburen/fix-lsp-formatting branch October 29, 2024 17:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

buf beta lsp formatting duplicates leading comments in file
2 participants